locked
Can i use composite pattern? RRS feed

  • Question

  • User-301840979 posted

    Hi,

    i'm new with design patterns and i'm not sure if in this situation i can use a composite pattern.

    The scenario is a web application for an address book : the address book cointains AddressBoookItem, generalization for Contact and ContactGroup. The last one is the composite object containing a collection of AddressBoookItem.

    With these scenario i'm sure that this is a composite pattern, but what is confusing me is that a contact may belong to many contactgroup. Does this request change the situation? Till now i thought that between the Leaf object and the Composite (in the composite pattern) there was a 1-to-m relationship (a composite may contains many leaf but a leaf is contained in only one composite object).

    Am i wrong?

    Can i still use the composite pattern ?

    And, the last question,

    How could i rapresent my scenario in a relational database? One table for the entire hierarchy or two table (Contact and ContactGroup) with a m:n relationship between them ?

     

    Thanks

    Wednesday, May 26, 2010 3:01 AM

Answers

  • User-952121411 posted

    My doubt is on the relationship between Leaf and Composite object in the Composite pattern, that is, a single Leaf object may belong to many Composite object ? Is there any limitation ?
     

    No a leaf is the most primitive object type in the Composite pattern and only belongs to a Single Composite object.  However there is no limitation on how many leaf nodes (objects) can exist for a single Composite object.  Just remember that in order to adhere to this pattern all Composite objects must adhere to the Component Abstract Class.

    With regard to the database structure i thought to three tables:

    - Contact  with fields contactid, name, email, faxNumber, PhoneNumber, Address, etc.

    - ContactGroup (used to categorize contact and group them in a convenient way)with GroupId, ParentGroupId, GroupeName fields.

    - GroupedBy table to represent the many to many relationship between Contact and ContactGroup (contactid, groupid)

    I thought to use only these tables, but i'm interested in your schema, could you explain it with some possible field definition?

    Yeah the above looks fine, but I might change the table named 'GroupedBy' to something more applicable like 'ContactGroupLookup'.  I think you may want to consider another level of normalization for the 'GroupName' column and making a table named 'Groups', so that just the ID (i.e. fkGroupID) exists in the ContactGroup table as opposed to text that is repeated over and over.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, May 26, 2010 3:40 PM

All replies

  • User-952121411 posted

    A few notes on the Composite Pattern that are important because the focus with that pattern is the treelike structure and how the parent component class (typically an Abstract Base Class) defines operations good for the parent and all of its children.  Typical methods would be 'Add' and 'Remove' children, as these methods can be treated uniformly from the top to the bottom of the Composite structure.  Also this pattern is applicable when you have an object that is going to have a collection of objects, and the collection of objects can be treated in the same manner as its parent.  I think a lot of times when we design classes that have properties that contain a collection of objects as a Property we sometimes back into this pattern inadvertently depending on the parent/child relationship (which is ok by the way).

    To get a more solid footing about the Composite Pattern and its uses check out as always the GOF Bible "Design Patterns Elements of Reusable Object Oriented Software" as they were the creators (or at least formal documenters) of this pattern along with the next few links:

    Composite Pattern:

    http://www.dofactory.com/Patterns/PatternComposite.aspx

    Composite Pattern in ASP.NET:

    http://msdn.microsoft.com/en-us/magazine/cc188707.aspx#S7

    Now in your case (Address Book) a lot will be solved simply by using generic object collections and designing your classed to have a 1:n relationship.  Even before a pattern is applied, you could potentially solve this with just creating your class structure 1st and having collection properties on your main class.  The problem in your case is can the Composite pattern truly be attributed to your design?  If not that's ok.  You would need to begin by designing your Component Abstract class that defines the methods that are usable by all Composite defined classes, so all Composite classes can be treated alike.  The leaf nodes may have their own functionality, but still adhere to the abstract class.  So in this case if you treelike Address book structure doesn't really adhere to all of the Composite pattern guidelines then you can just shift focus to solving the overall problem without the pattern.

    Regardless to modernize some of the examples you see surrounding the Composite Pattern, you will be using Generic Object Collections in .NET.  Take a look to the following for more information:

    .NET Object Collections Using Generics 101: 

    http://allen-conway-dotnet.blogspot.com/2009/11/net-object-collections-using-generics.html

    How could i rapresent my scenario in a relational database? One table for the entire hierarchy or two table (Contact and ContactGroup) with a m:n relationship between them ?

    I think you can have the following tables:  AdressBook, AdressBookItems, Contacts, ContactGroups, ContactGeneralizations with a 1:n relationship between AddressBook and AddressBookItems, and the same for AddressBook and AddressBookItems.  I am actually basing this just on the English definition of the table names, but knowing what data comprises the tables could change the schema. 

    Hope this helps! Smile

    Wednesday, May 26, 2010 10:51 AM
  • User-301840979 posted

    Thank you very much for your answer.

    My intention is to practise on using pattern and the address book seemed to me a good exercise.

    My doubt is on the relationship between Leaf and Composite object in the Composite pattern, that is, a single Leaf object may belong to many Composite object ? Is there any limitation ?


    With reguard to the database structure i thought to three tables:

    - Contact  with fields contactid, name, email, faxNumber, PhoneNumber, Address, etc.

    - ContactGroup (used to categorize contact and group them in a convenient way)with GroupId, ParentGroupId, GroupeName fields.

    - GroupedBy table to represent the many to many relationship between Contact and ContactGroup (contactid, groupid)


    I thought to use only these tables, but i'm interested in your schema, could you explain it with some possible field definition?


    Thanks!

    Regards.


    Wednesday, May 26, 2010 1:37 PM
  • User-952121411 posted

    My doubt is on the relationship between Leaf and Composite object in the Composite pattern, that is, a single Leaf object may belong to many Composite object ? Is there any limitation ?
     

    No a leaf is the most primitive object type in the Composite pattern and only belongs to a Single Composite object.  However there is no limitation on how many leaf nodes (objects) can exist for a single Composite object.  Just remember that in order to adhere to this pattern all Composite objects must adhere to the Component Abstract Class.

    With regard to the database structure i thought to three tables:

    - Contact  with fields contactid, name, email, faxNumber, PhoneNumber, Address, etc.

    - ContactGroup (used to categorize contact and group them in a convenient way)with GroupId, ParentGroupId, GroupeName fields.

    - GroupedBy table to represent the many to many relationship between Contact and ContactGroup (contactid, groupid)

    I thought to use only these tables, but i'm interested in your schema, could you explain it with some possible field definition?

    Yeah the above looks fine, but I might change the table named 'GroupedBy' to something more applicable like 'ContactGroupLookup'.  I think you may want to consider another level of normalization for the 'GroupName' column and making a table named 'Groups', so that just the ID (i.e. fkGroupID) exists in the ContactGroup table as opposed to text that is repeated over and over.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, May 26, 2010 3:40 PM