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

Groups > comp.lang.java.programmer > #30714 > unrolled thread

Re: "How do you arrive at classes?"

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#30714 — Re: "How do you arrive at classes?"

On 1/14/2015 9:36 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> Now, a student asked me: »How do you arrive at classes?«,
>
>    Thank you all for your answers!
>
>    I have written a German-language web page to answer
>    the question. Here are some parts of it in English:
> [...]
>    3. hints
> [...]
>    - find fields (variables) that belong together and
>      group them into one class, than add methods for them

     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.

     From the perspective of the Java language (not necessarily
that of all O.O.P. frameworks), methods and fields are simply
"members" of their classes; they are peers, without primacy.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [next] | [standalone]

#30715

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       |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web