Re: Help on choosing a valid pattern: composite or not?



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



.



Relevant Pages

  • Re: Simples Rules make creating Big Balls of Mud impossible.
    ... Do you do what I have called "client / service" programming or the Other ... site that does a pretty good job of describing the Layers pattern. ... Services have explicit boundaries -- aka clients: ... without requiring a recompile. ...
    (comp.object)
  • Re: 2 reasons my 5 ball is progressing well
    ... Because they both train diferent things. ... it will encourage a more consistent pattern. ... As to how much to practice. ... variety than just the 5 ball cascade. ...
    (rec.juggling)
  • Re: 2 reasons my 5 ball is progressing well
    ... >1) Practice clean- very important, I just recently learned from John ... >pattern off balance. ... usual trainers or bare feet. ... first dozen or so throws being consistently lower the ...
    (rec.juggling)
  • Re: NHPs produced without CD
    ... that display the same pattern without common descent. ... "The fractal hierarchy is evidently the least-energy pathway to ... What makes it a "tree" exactly? ...
    (talk.origins)
  • Re: PRACTICE!!!
    ... I had the fortune of meeting Yuriy Pozdnyakov (The Kiev State ... My old practice session was very similar to what others have been posting. ... Yuriy recommended a new practice style and I qualified my next pattern 1 ...
    (rec.juggling)