Thanks everyone, you've given me a lot of places to start.
Matt
On 3/26/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
just look at wicket
component=leaf
grouper=markupcontainer
there is no nice and neat pattern that will do everything you want, its
just not how inheritance works. this is why in wicket Page class has
oncomponenttag() eventhough it doesnt make sense there.
-igor
On 3/23/07, Matt Welch <[EMAIL PROTECTED]> wrote:
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
