As the subject indicates, this isn't a question specific to Wicket (although
it WILL eventually involve Wicket to display these objects), so if you feel
I should post this elsewhere, feel free to tell me so, however it seemed
like a pretty bright bunch of Java guys hang around here so I'm hoping for
some insight.

I've been tasked with implementing a rather curious (to me anyway)
hierarchical object structure. Most of the objects in this structure serve
no other purpose than to group the objects below them; it's only at the
final leaf levels that there are some significant behavioral difference in
the objects. For lack of a better example, I'll call these objects Grouper1,
Grouper2, Grouper3, and Leaf. So I might have a structure that looks like:

Grouper1
--Grouper2
----Grouper3
------Leaf
------Leaf
------Leaf
----Grouper3
------Leaf
------Leaf
------Leaf

It can also look like this:

Grouper1
--Grouper3
----Leaf
----Leaf
----Leaf
--Grouper3
----Leaf
----Leaf
----Leaf

Or like this:

Grouper1
--Leaf
--Leaf
--Grouper2
----Grouper3
------Leaf
------Leaf
------Leaf
----Grouper3
------Leaf
------Leaf
------Leaf

Or even like this:

Grouper3
--Leaf
--Leaf
--Leaf

Although I'm willing to exclude that last example (with something other than
a Grouper1 at the top) if it helps simplify things any.

As you can see almost all objects in the hierarchy can exist at any level.
Only the leaf node has any properties beyond those shared by all of the
other objects. And before you ask, despite the fact that the branch items
are so similar, they do have different labels that are important to the
people using the hierarchy. I'm just trying to determine if those labels are
important to the domain model.

I started to model this using simple inheritance. Something like the
following:

public abstract class MyHierarchyObject{
   private String commonAttribute1;
   private boolean commonAttribute2 = false;
   private List<MyHierarchyObject> children = new
ArrayList<MyHierarchyObject>;
   private MyHierarchyObject parent;  //the association needs to be
bidirectional for up and down navigation
   ...
}

public class Grouper1 extends MyHierarchyObject{
}

etc. etc.

Of course, I realized after just a few seconds that this seemed a little
silly since I was going to end up with at least three classes with either no
behavior or properties or only extremely minor changes to the abstract
class's properties like setting commonAttribute2 to true by default.

So does using inheritance like this still make sense or should I do
something like make the MyHierarchyObject not abstract and add a Type
property that can be populated from an enum with elements like Grouper1,
Grouper2, and Grouper3? What about the leaf node. It's not allowed to have
children but because it can be a child of any of the Groupers, it seems like
it needs to extend MyHierarchyObject in order to fit into the child parent
model. Should I put the children related methods into an interface that only
the Grouper classes implement? Of course that only works if I use the
inheritance model; maybe that's a good reason to use it? Or is there a
design pattern I'm missing in all of this that might help me.

I've been thinking about this for so long now that I'm afraid I'm too deep
into it and not thinking clearly about the best approaches. That's why I'm
posting here. Unfortunately, the hierarchy is quite a bit more complex than
this example, but I think if I can solve this level of complexity, I can
apply similar logic to the rest of the hierarchy that I didn't represent
here.

Thanks for reading such a long post.

Matt
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to