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