Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #30715

Re: "How do you arrive at classes?"

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>

Show all headers | View raw


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


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