Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #30715
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: "How do you arrive at classes?" |
| Date | 2015-01-15 14:28 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <m98iqc$h40$1@dont-email.me> (permalink) |
| References | <classes-20150114054030@ram.dialup.fu-berlin.de> <classes-20150115032323@ram.dialup.fu-berlin.de> <m98g61$c3o$1@dont-email.me> |
On Thu, 15 Jan 2015 08:43:48 -0500, Eric Sosman wrote: > > Sometimes it's the other way around: You start from the > behaviors you want to model, and from those you discover what fields the > class will need to support those behaviors. That is, you sometimes > begin with the methods and derive the fields. > > Perhaps the clearest example of behaviors-then-data as > opposed to data-then-behaviors is in implementing an interface: > The interface says nothing about the data and everything (well, > everything it can) about the methods. If you are implementing the > Iterator interface you must write hasNext() and next(), and although > it's clear that you must keep track of the iteration's progress there's > no specification of what sort of data you must maintain to do so. > In general I think many people start defining a class by naming it and then adding its identifier or key attributes plus a few of the obvious non-key attributes and the constructor(s) and methods needed to access the attributes. Then, as first the design and then the system develops, you add more attributes and methods as needed. It may be worth mentioning a really traditional way of determining what attributes are needed: start by fleshing out the UI in terms of reports and display screens that the users require and include all the data items that the users want to see in them. Then work backwards from these outputs, following the system data flow back to the inputs and make sure that all the data items in the output also appear as attributes of the appropriate classes/entities and they all are either generated internally or are present in the system's input screens or data feeds. I first learnt this approach back in the days of punched cards, spinning reels of mag.tape and lineprinters. Then I subsequently found it just as useful for populating first IDMS records and then RDBMS tables with data fields. Its only a small paradigm change from a database schema that defines tables and relationships to a collection of classes and their relationships, so this method of populating objects with attributes by following the data flows from required outputs back to system inputs will be equally valid in an OO world. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: "How do you arrive at classes?" Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-01-15 08:43 -0500 Re: "How do you arrive at classes?" Martin Gregorie <martin@address-in-sig.invalid> - 2015-01-15 14:28 +0000
csiph-web