Composite pattern

Encyclopedia : C : CO : COM : Composite pattern

This article or section is in need of attention from an expert on the subject.
Please help recruit one, or improve this page yourself}} if you can. See [discussion page] for details.

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 composite 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 homogeneous. (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.)

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.

Contents

1 Structure
2 Examples

2.1 Java
2.2 Perl
2.3 Perl (complex example) (needs revising)

3 See also
4 External links

Structure

Component
* declares the interface for object composition
* implements default behaviour
* declares an interface for accessing and managing the child components

Leaf
* represents leaf objects in the composition

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

Client
* manipulates objects in the composition through the Composite interface

Examples

Java

import java.util.*;

interface Component 


class Composite implements Component 


public String defaultMethod() 


public ArrayList getChildren()       
public boolean addComponent(Component c)        
public boolean removeComponent(Component c)     
}


class Leaf implements Component 


public String defaultMethod()                   
public ArrayList getChildren()       
public boolean addComponent(Component c)        
public boolean removeComponent(Component c)     
}


class CompositePattern 
}

The output is: "(Europe: (England: London) (France: Paris) )"

Perl

The following Perl program illustrates the 'Europe' example given above and will output:

(Europe: (England: London) (France: Paris))

package Composite;
sub new ,
}, $class);

return $self;

}

sub default_method . ':';

foreach my $component (values % })

return $s . ')';

}

sub add_component = $component; }

sub remove_component ); }

package Leaf; sub new , $class);

return $self;

}

sub default_method ; }

## client

my $england = Composite->new('England');

my $york = Leaf->new('York'); my $london = Leaf->new('London');

$england->add_component($york); $england->add_component($london); $england->remove_component($york);

my $france = Composite->new('France'); $france->add_component(Leaf->new('Paris'));

my $europe = Composite->new('Europe'); $europe->add_component($england); $europe->add_component($france);

print $europe->default_method() . "\n";

Perl (complex 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 , $type;
}


sub next 
sub set_next 
sub previous 
sub set_previous 
sub append 
$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 ;
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 
sub previous_sort 
sub set_next_sort 
sub append_sort 


sub next_size 
sub previous_size 
sub set_next_size 
sub append_size 


sub next_save 
sub previous_save 
sub set_next_save 
sub append_save 


# directly return references to objects that compose us:
# method B: see text below


sub get_sort_order 
sub get_size_order 
sub get_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 the implementation. 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".

External links

[Description from the Portland Pattern Repository]
[Class::Delegation on CPAN]
[Chinese Ring Puzzle Applet]
["Monkey Delegation"] by Michael G. Schwern
[Lazy Load] by Martin Fowler
["The End of Inheritance: Automatic Run-time Interface Building for Aggregated Objects"] by Paul Baranowski
[Composite Pattern] from Ward Cunningham's Portland Pattern Repository
[Composite Pattern] by Vince Huston

Parts of this article originated from the Perl Design Patterns Book

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.