Re: Help on choosing a valid pattern: composite or not?
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Mon, 28 Nov 2005 19:27:00 GMT
Responding to Moleti...
I'm just writing a toy application using C# to make some practice with Patterns and layers.
Now I'm faced with the "huge" dilemma of which pattern best suits the object oriented world I'm building.
I have one object which represents a net, whose node can either be: 1. A net 2. A proper node (of various kinds; Factories?!)
I agree with Nicholls that you need to put more words around 'net'.
Both the "node" and the "net" have similarities in their interfaces.
For example: Net: - Add a node - Delete a node - Execute a node
What you seem to be talking about here are collection classes associated with relations between [Net] and [Node]. Since a [Net] seems to be recursive, I agree that this suggests that the Composite pattern might be appropriate:
* composed of
[NetEntity] --------------------------+
A |
| R1 | R2
+-------+--------+ |
| | 1 |
[Node] [Net] --------------------+The operations you describe would be operations of the collection class that implements the R2 relationship.
Node: - Link to node (Could be translated as: Add a link to a node) - Unlink to node (Could be translated as: Delete a link to a node) - Execute
This indicates an orthogonal set of relationships around Nodes. For example, if one is doing a POS catalogue, [Net] might be a category hierarchy while [Node] represents leaf items in a category. However, that is only the navigational view where a [Item] is quite abstract. In practice, items will have their own independent product hierarchies so it is convenient the separate them:
* composed of
[CatalogueElement] ----------------------+
A |
| R1 | R2
+-------+--------+ |
| | 1 |
[Item] [Category] ------------------+
| 1
|
| R3
|
| corresponds to
| 1 1
[Product] [ProductLine] -------------+
| | |
+-------+----------+ |
| R4 | R5
_ |
V * composed of |
[ProductElement] ----------------------+So the links you are referring to here would be instantiating the R3 relationship. In this case the [ProductElement] hierarchy is captured in its own Composite pattern. (In practice this is simplistic because, among other things, [Product] will probably be subclassed -- its just an example.)
Node have some properties that Net doesn't have, and the clients are expected to deal with them.
If it's possible, I would like to implement clients so that
they shouldn't have to care about the difference between "nodes" and "nets".
Without taking into account the "properties" aforementioned, from the GoF book I understand that the "Composite" pattern would be the
route to take.
The question is, is still "Composite" a good pattern to use if those "properties" are to be considered from a client stand point?
All the Composite is describing is a hierarchical organization. All of the structure is defined through the instantiation of the R2 relationships. However, it is often useful to maintain that level of abstraction. IOW, the only clients using the structure would be those who need to navigate among its members. So one would likely separate out the detailed semantics into other objects, as in the POS example above.
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- References:
- Help on choosing a valid pattern: composite or not?
- From: Carmine Moleti
- Help on choosing a valid pattern: composite or not?
- Prev by Date: Re: OOAD Study Guide
- Next by Date: Re: Help on choosing a valid pattern: composite or not?
- Previous by thread: Re: Help on choosing a valid pattern: composite or not?
- Next by thread: Re: Help on choosing a valid pattern: composite or not?
- Index(es):
Relevant Pages
|