extending or modifying Data class??

[Chandu onwards]

Dear Group,
I'M through with my assignment, I have modified the Data class, but now i'm unable put any valid reasons for my choice in Design choice document.
can some body suggest me something in this regard!!
[ December 25, 2002: Message edited by: Chandu onwards ]

[John Lee]

Simplicity.

[Chandu onwards]

Hi Don Liu,
Thanks for your continuous and timely response.
Thanks,
Chandu

[John Lee]

My pleasure! Good luck with your assignment!

[Peter den Haan]

Originally posted by Don Liu:
Simplicity.

One of the attributes of a well-designed class is "coherence". An incoherent class does a number of different things that are loosely releated at best. A coherent class does exactly one thing and does it well.
To get coherent classes, it makes sense to look at them in terms of "responsibility". What does the class do? What is it responsible for? Anything that falls within that responsibility should go into the class; other tasks should go somewhere else. You keep on moving code around, splitting classes and reformulating your understanding of a class' responsibilities until each class has a single responsibility which doesn't overlap with any of the other classes (although such a responsibility may well decompose into multiple smaller responsibilities, e.g. the class that has the responsibility for providing access to a remote database may delegate some work to a different class that has the responsibility for managing record locks; these responsibilities are formulated at completely different levels and correspondingly these classes work at different levels).
Once you're clear about what Data is responsible for, you can decide where, say, a new method such as criteriaFind() goes.
- Peter