Composite pattern

You must add a |reason= parameter to this Cleanup template – replace it with {{Cleanup|April 2005|reason=<Fill reason here>}}, or remove the Cleanup template.

In Computer Science, the composite pattern is a design pattern: "A general solution to a common problem in software design."

Motivation: In object-oriented programming, a Composite is an object (e.g. a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would a group of them. The operations you can perform on all the composited objects often have a least common denominator relationship. For example, when resizing a single shape to fill the screen, surely you would expect/desire that resizing a group of shapes would have the same effect.

When to use: You find that you are using multiple objects in the same way, and often have nearly identical code to handle each of them -- the only differences being that you are manipulating an instance of a 'circle' versus a 'square', for instance. Useful if differentiation doesn't need to exist, and it would be easier to think of them as homogenous. (Of course, you could still provide functionality to manipulate only a single instance -- like selecting an item from a list instead of operating on the whole list.)

Structure

File:Compositepattern.png

Component
- declares the interface for object composition
- implements default behaviour
- declares an interface for accesing and managing the child components

Leaf
- represents leaf objects in the compostion

Composite
- defines behaviour for components having children
- stores child components
- implements child-related operations io the Component interface

Client
- manipulates objects in the composition througth the Composite interface

Concrete Example (needs revising): 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.

External links

Parts of this article originated from the Perl Design Patterns Book

Structure

See also

External links