CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 4 of 4

Thread: Understanding the Composite Design Pattern

  1. #1
    Join Date
    Jun 2015
    Posts
    1

    Understanding the Composite Design Pattern

    I have been doing some class diagram modeling to practice design using the composition design pattern and I was wondering if the abstract component must have an operation that is common among all of its children; rather, instead could the abstract component only have attributes common to all children and operations used only by the composite class?

    A use case for this might be when modeling something such as the parts of a story, or modeling the grammar of a language, where objects of these types would be used by client classes but not necessarily do something in and of themselves.

    Thoughts?

  2. #2
    Join Date
    Jun 2015
    Posts
    208

    Re: Understanding the Composite Design Pattern

    Quote Originally Posted by Psiryan View Post
    I was wondering if the abstract component must have an operation that is common among all of its children; rather, instead could the abstract component only have attributes common to all children and operations used only by the composite class?
    Wouldn't that defy the purpose of the Composite pattern which is to treat Leaf and Composite as equal and unified as possible. Otherwise the pattern falls apart into just an ordinary tree with nodes and leaves.
    Last edited by tiliavirga; July 10th, 2015 at 11:39 AM.

  3. #3
    Join Date
    Jan 2010
    Posts
    1,133

    Re: Understanding the Composite Design Pattern

    Yeah - the whole point of the Composite pattern is to have an object composed out of smaller parts, but have the client code treat it the same way as any individual part (by letting the concrete subclass, which may or may not be a composite object, handle all the type-specific details).

    For example, consider a drawing or a diagramming application with a component that's responsible for telling various shapes when to draw themselves, by calling a Draw(...) method on each one. Assume now that this application allows the user to define a composite shape, that's implemented using the Composite pattern (that is, it derives from the same abstraction as the rest of the shapes, and is made of a bunch of other shapes).
    The component that initiates the drawing of these shapes doesn't have to know anything about this composite shape, all it sees is an abstract Shape object with a Draw(...) method, and that's all it cares about. You don't need to change the component, it will work the same as before.

    Now, that doesn't mean that various subclasses and the composite itself cannot have their own, type-specific properties and attributes - they can.

    Also note this: if you push some of the operations that apply only to some classes to the root of the hierarchy, then because of the hierarchy structure, all classes will inherit these operations, even if it doesn't make sense for many of them. If that's the case, then that's an indication that maybe the Composite pattern may not be the way to go.

    That said, you may have a bunch of objects that form a graph with a similar structure, but that in itself doesn't constitute an example of the Composite pattern - patterns are not only about structure, they are about solving specific kinds of modeling problems.

  4. #4
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: Understanding the Composite Design Pattern

    Quote Originally Posted by Psiryan View Post
    A use case for this might be when modeling something such as the parts of a story, or modeling the grammar of a language, where objects of these types would be used by client classes but not necessarily do something in and of themselves.

    Thoughts?
    If you have a tree-like structure in your data, there are several common ways to represent it in your code. Note that a tree is a special type of graph, but this goes for any type of graph.
    In my experience, the method that is typically most efficient is to store your node data in a flat list (std::vector) and the relations between nodes either in an adjacency matrix (for dense or small graphs) or an edge list (for sparse graphs).
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)