Unification of Methods and Functions

[David MacQuigg]

On Mon, 17 May 2004 16:40:00 +1200, Greg Ewing
<greg at cosc.canterbury.ac.nz> wrote:

>David MacQuigg wrote:
>> James has been telling me it is terribly wrong to keep data as
>> attributes of classes
>
>There's nothing inherently wrong with that, as long as
>you're certain you will only ever want one instance of that
>piece of data.
>
>In my chip example, you might want to keep a count of the
>total number of transistors in your chip as a class variable
>of the Transistor class. But that only works if your program
>only ever deals with one chip at a time. If there can be more
>than one chip, then you'll need a Chip class whose instances
>either keep a count of Transistors contained in that chip,
>or have a method that can compute the count when needed.
>
>Even if you think you will only deal with one chip at a
>time, it would be good design practice to plan on having
>a Chip class anyway, in case the requirements change. The
>amount of work involved is about the same either way, and
>the design which avoids class variables is more flexible.

This makes a lot more sense than a total ban on data in classes.

I think the generalization to a "multi-zoo" program probably belongs
in the third example, along with perhaps some techniques like James
showed to make the code more robust by generating the classes rather
than writing them.  The first and second examples ( Animals_1 and
Animals_2 need to be very simple.

-- Dave