Often the line along which to split a class is pretty obvious. A rule
of thumb I follow is to describe the class in one sentence and then
split it into multiple classes on every instance of the word "and".
E.g. go from a class that "makes a request to the server and parses
the XML and displays it in a grid control" to a class that makes
server requests, a class that parses XML and a class that manages the
When I find I can't do that, it's usually the case that I haven't
clearly allocated responsibilities among a cluster of related classes.
In that case, refactoring is a bit more work and involves moving
behaviour between classes until it feels right. Again, describing a
class to your pair or writing the descriptions on index cards on your
desk can help. Classes with vague descriptions are something to look
out for. Class names or descriptions containing words like "manager",
"data", "helper", "object", or containing the names of patterns are
good suspects for suffering from badly assigned responsibilities.
Such classes often disappear while refactoring, to be replaced by
classes with names that make sense in domain terms.
Describe classes by their roles and responsibilities. Objects are things that do things.
My usual advice about using servlets or session EJBs I advise teams to
use the J2EE APIs purely as an adapter between the application server
and a clean domain model and view layer. Write a quick shim against
the J2EE APIs, concentrate on writing good clean object-oriented code
in the rest of the app and everything falls out neatly.
Of course, the "writing good clean object-oriented code" topic is a
whole nuther kettle of fish.
Inspiration: Nat Pryce