Where's the domain?
April 12th, 2005
Koz Speaks: Where's the Domain?
While I fully understand the pledge for a more active object model, I've found myself backing away from it lately, too. The problem is that many objects seem to have so many roles, and are used to perform so many operations, that it just becomes unfeasible to put all those methods in one class. For example, you have a tree you want to have all leaves of. Ah, call Node.getChildren() recursively, you say. And when the node at hand is a leaf, it returns itself. But: sometimes I want all the leaves. Sometimes I only want the leaves of certain branches. And sometimes, I don't only want the leaves, I want the internal nodes too. What's one supposed to do? Implement Node.getChildren(), Node.getChildrenOnCondition(Condition), and Node.getChildrenIncludingInternalNodes()? Or get some hefty Visitors, and have those "external" classes decide which logic to use? Which object model will look cleanest, do you think?
I'm all for the naked objects approach, but I'm having trouble to keep all the "aspects" of an object cleanly separated.
Writing that last sentence, makes me wonder of the word "aspects" there is the same as the word "aspect" in "AOP". Stuff to ponder ...
April 21st, 2008 at 10:18 PM Where are you proposing to put this Node related logic if not in the node class? into some other class which suffers from the same 'gets big fast problem' or into a number of smaller classes which becomes difficult to manage? Personally I'll have "Node.listChildren();" and "Node.listChildren(Predicate p);". Predicates are a pretty well understood way of dealing with collections of objects.