Composite pattern

de:Kompositum (Entwurfsmuster)

In computer programming, particularly object-oriented programming, a composite pattern is one of the design patterns to decompose objects into their parts, and reassemble them in whichever combination one needs with "has-a" relationships. That is to say, to break things into the largest parts that still allow reuse of the parts, and build objects of those.

The other definition is to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

When to use: Any time there is partial overlap in the capabilities of objects.

Objects may be members of a number of linked lists in our system. The linked lists organize the objects by different criteria.

 package LinkedList;
 use ImplicitThis; ImplicitThis::imply();
 
 sub new {
   my $type = shift;
   bless { next=>'', previous=>'' }, $type;
 }
 
 sub next { return $next; }
 sub set_next { $next = shift; return 1; }
 sub previous { return $previous; }
 sub set_previous { $previous = shift; return 1; }
 sub append { 
   my $ob = shift; $ob->isa(__PACKAGE__) or die;
   $next or do { $next = $ob; $ob->set_previous($this); return 1; }
   $ob->set_next($next);  $next->set_previous($ob);
   $ob->set_previous($this); $this->set_next($ob);
   return 1;
 }

This can be inherited, but inheriting it multiple times doesn't do any good: one only ever has one instance of the LinkedList this way - oneself. Using composition gives the desired result:

 package TriceQueuedObject;
 use LinkedList;
 use ImplicitThis; ImplicitThis::imply();
 
 sub new {
   my $type = shift;
   my $me = { 
     sort_order => new LinkedList,
     size_order => new LinkedList,
     save_order => new LinkedList,
     @_
   };
   bless $me, $type;
 }
 
 # create accessors that defer the action to each object, for each object composing us:
 # method A: see text below
 
 sub next_sort { return $sort_order->next(); }
 sub previous_sort { return $sort_order->previous(); }
 sub set_next_sort { return $sort_order->set_next(@_); }
 sub append_sort { return $sort_order->append(@_); }
 
 sub next_size { return $size_order->next(); }
 sub previous_size { return $size_order->previous(); }
 sub set_next_size { return $size_order->set_next(@_); }
 sub append_size { return $size_order->append(@_); }
 
 sub next_save { return $save_order->next(); }
 sub previous_save { return $save_order->previous(); }
 sub set_next_save { return $save_order->set_next(@_); }
 sub append_save { return $save_order->append(@_); }
 
 # directly return references to objects that compose us:
 # method B: see text below
 
 sub get_sort_order { return $sort_order; }
 sub get_size_order { return $size_order; }
 sub get_save_order { return $save_order; }

"Method A" and "method B" illustrate two very different approaches to giving users of the object access to the parts. "Method A" creates all new accessors which do their work by calling accessors in the composing objects. "Method B" simply returns the composing objects and lets the user call the methods directly. For example:

 # using method A:
 
 $ob->next_sort($ob2);
 
 # using method B:
 
 $ob->get_sort_order()->set_next($ob2);

Which method is preferable varies. If the object is merely a container for other objects, B makes more sense. If the object is a Facade, providing a new interface to several objects, A makes more sense. If the contained objects are considered to be implementation dependent, and having to support returning intermediate objects in the future is not desirable, A allows better hiding of theimplementation. B makes for shorter code and less typing when the relationship between the objects is not likely to change.

Each LinkedList instance is a "delegate" in this example. The methods that propagate requests to them are "delegate methods".

Compose means a special thing: it refers to building objects using DelegationConcept. Delegation-composition hangs onto constituent parts-using references. By contrast, mixins inherit from each part. MixIns prevent returning a WholeObject in response to requests for information, and they prevent having more than one of any given part.

See also

• Mixin
• Facade pattern
• Decorator pattern
• Whole object
• Class::Delegation on CPAN
• Law of Demeter
• Delegation concept
• Builder pattern
• Abstract factory pattern

External links

• Description from the Pattern Digest (http://patterndigest.com/patterns/Composite.html)
• Description from the Portland Pattern Repository (http://c2.com/cgi/wiki?CompositePattern)
• Chinese Ring Puzzle Applet (http://www.cs.oberlin.edu/~jwalker/puzzle/)
• "Monkey Delegation (http://magnonel.guild.net/~schwern/talks/Design_Patterns/full_slides/slide025.html)" by Michael G. Schwern
• Lazy Load (http://martinfowler.com/eaaCatalog/lazyLoad.html)
• "The End of Inheritance: Automatic Run-time Interface Building for Aggregated Objects (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/149878)" by Paul Baranowski

The article is originally from the Perl Design Patterns Book