• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Composite Pattern

 
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everybody,
I think i pretty much understand this pattern and it seems its benefits are seen when a client wants to treat a primitive and a composite in a similar way.
I am creating a GUI that will have a JTree. On this tree there will be a primitive type ( a leaf ) and a composite types ( branch )which may hold a number of primitive types. It is possible to add children to all nodes so that a node that was once a leaf may become a branch.
There are no real differences in the behaviours of the two node types. Except one will have children and the other wont. However there are some differences in the attributes that will have values depending on whether that node has children or not. E.g if the node has children attributeA will have no value as a node that has children does not possess this attribute.

So what im wondering is if i should define two different classes based on the composite pattern for the different node types as only some attributes are relevant when a node is of a certain type.
However if i do this it will mean that even though i may hold the composite interface for a leaf node, if i add a child to that node, then it becomes a branch and i have to create a new branch type, copy some values from the leaf type into the branch type and then reassign the concrete branch type to the composite interface. This does not at all seem like somthing i should be doing.
So on one hand i think i have an argument for using the composite pattern and on the other i have an argument for not using it. Anyone able to offer an oppinion on which is the most convincing?
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make all your nodes Composite. You won't have to do the conversion, from leaf to branch, when adding more than one element to a node.
[ August 20, 2002: Message edited by: Jose Botella ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What if you combined the state pattern with your composite? The composite could hold the things that are identical for leaves and branches and hold a reference to a state which hold the differences. When a leaf becomes a branch, you only have to substitute the state.
How does that sound to you?
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
What if you combined the state pattern with your composite? The composite could hold the things that are identical for leaves and branches and hold a reference to a state which hold the differences. When a leaf becomes a branch, you only have to substitute the state.
How does that sound to you?


Sounds like a very good idea Ilja. I need to think about it for a while now......
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
What if you combined the state pattern with your composite? The composite could hold the things that are identical for leaves and branches and hold a reference to a state which hold the differences. When a leaf becomes a branch, you only have to substitute the state.
How does that sound to you?


Hi Ilja,
I can see the benefit in that i can swop in the state objects based on the changes in the node. However each of these state objects will have different attributes for which i will need accessor methods. So that means i would not be able use an interface method. To get the data values of a particular node i will need to know the type of its state object so i loose the benefit of the interface......maybe i am confusing matters

John
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
However each of these state objects will have different attributes for which i will need accessor methods
Do these attributes have anything in common (such as they are all of type "String")? If so, you could conseider putting a more generic "getter" in your interface which gets a named attribute.
Don't get hogtied by assuming that JavaBeans getter/setter pairs are all there is to attribute access.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, possibly you have to cast your states when you need to access specific attributes.
OTOH perhaps your states should have more *behaviour* and expose less attributes. It's hard to say without knowing more.
Can you post some code and explain how it gets used?
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
Yes, possibly you have to cast your states when you need to access specific attributes.
OTOH perhaps your states should have more *behaviour* and expose less attributes. It's hard to say without knowing more.
Can you post some code and explain how it gets used?


Well the states are going to represent different types of nodes that can appear in a JTree. To keep it simple for now i will say that there are two types of node, a branch and a child. Branch nodes for example have different attributes to a child. Using the state pattern will allow me to keep the different attributes seperate and i can substite the state objects when a node changes from a child to a branch.
Upon clicking on the tree i will offer different functionality based on the type of the node. This will be easily done as i will just test for the type of the state object. However i then want to display the attributes of this node in another part of the GUI. So this means i need a way of getting the attribute values and then build a GUI to display them.
I suppose it would be possible to do as Franks says as they are mostly String values. Then at least i can use a generic getter method and place it in the State interface. However i wondering what is the benefit/advantage of having this generic getter method when the class using it will implicitly need knowledge of the type of the State object so that it can pass the correct attribute names to receive back their values. As i will have checked the type of the state object when the node is selected on the tree, is it not the as well to cast it at that point and use defined accessor methods. I suppose it gives a cleaner interface to use alright........
John
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by John Ryan:
Upon clicking on the tree i will offer different functionality based on the type of the node. This will be easily done as i will just test for the type of the state object.


Possibly you could even do that *without* testing for the type at all. After all, the nodes themself already know their own type, so if you could *them* get to offer the functionality to the user...

However i then want to display the attributes of this node in another part of the GUI. So this means i need a way of getting the attribute values and then build a GUI to display them.


What if the nodes themself would build the GUI? Or you could use the Visitor pattern, if you needed more flexibility. See http://exciton.cs.oberlin.edu/javaresources/DesignPatterns/VisitorPattern.htm
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:

What if the nodes themself would build the GUI? Or you could use the Visitor pattern, if you needed more flexibility. See http://exciton.cs.oberlin.edu/javaresources/DesignPatterns/VisitorPattern.htm


Hi Ilja,
Thanks for your comments. There is however one problem with your ideas i think . I have designed the GUI using MVC so that would prevent me from putting this functionality into what would be considered model classes......
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by John Ryan:
Thanks for your comments.


You're welcome!

There is however one problem with your ideas i think . I have designed the GUI using MVC so that would prevent me from putting this functionality into what would be considered model classes......


By using the Visitor pattern, you don't put any GUI logic into the model. Did you take a look at it?
Let's look at an example (and for the moment ignore that the type is determined by a State).
Say, your Controller gets notified that the user clicked on a Node - now it has to find the adequate GUI to present to the user. Your Controller therefore implements the NodeVisitor interface and visits the Node:
node.accept(this);
The node knows its type, so it can call the appropriate method on the visitor (in this case the controller):
void accept(NodeVisitor visitor) {
visitor.visitFooNode(this);
}
Now in visitFooNode the Controller can cause the GUI to act appropriately for this type of node.
Of course you have to adjust this pattern to your needs, but I hope the principles are a little bit clearer now...
[ August 23, 2002: Message edited by: Ilja Preuss ]
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:

Of course you have to adjust this pattern to your needs, but I hope the principles are a little bit clearer now...
[ August 23, 2002: Message edited by: Ilja Preuss ]


Thanks Ilja. As u said i will have to adjust the pattern. More than likely my accept method in the Node object will change to call the accept method on the state object. The state object will then call the correct visit method in the controller.
void accept(NodeVisitor visitor) {
state.accept(this, visitor);
}
The state visit method will have to pass both itself and the node object to the controller(visitor) handler method as it will be necessaryy to extract attribute values from both of them..........
State accept method
void accept(Node node, NodeVisitor visitor) {
visitor.visitFooNode(this, node);
}
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I was thinking along similar lines...
OTOH, I wouldn't be sure about the appropriateness of this solution until I saw it in action, so look out for smells in the code (as you should do always, anyway).
For example, perhaps the design could benefit from a simplified form of the Role pattern - that is, the state could itself implement the Node interface, delegating all non-State-specific calls to the actual Node. This way, you wouldn't have to pass two arguments to the Visitor, for example. Hard to say wether that would be justified without knowing more intimate details about how the nodes get used, though...
[ August 26, 2002: Message edited by: Ilja Preuss ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:

Don't get hogtied by assuming that JavaBeans getter/setter pairs are all there is to attribute access.


BTW, there is a very good article on "Dealing with Properties" by Martin Fowler.
 
See where your hand is? Not there. It's next to this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic