«

»

Nov 19

Print this Post

Design patterns: composite

While describing iterator pattern on previous post I mentioned it was a part of a bigger chapter in the Head First: Design Patterns book. The second design pattern described in the chapter is called composite. The composite pattern helps us create tree structures in our code. The book example this time is pretty straight-forward but the end of it shows the power of iterator and composite together.

Book example

We’re still with our merged restaurants. It’s easy to add more restaurants and merge their menus into one. We have our iterators to traverse through all menus and print them. But just when we thought it was safe we received a request we hadn’t expected: they want us to implement sub-menu.

The time has come to refactor all the code we’ve created so far! We’ve reached a level of complexity such that if we don’t rework the design now, we’re never going to have a design that can accommodate further acquisitions or sub-menus. Is the composite pattern the direction we should follow?

The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Composite pattern's diagram

Composite pattern

The Component defines an interface for all objects in the composition: both the composite and the leaf nodes. It may implement a default behavior for add(), remove(), getChild() and its operations. We’re going to implement MenuComponent in this place.
The Composite‘s role is to define behavior of the components having children and to store child components. In our implementation Menu class will become composite.
The Leaf defines the behavior for the elements in the composition. A leaf has no children. MenuItem class will be our leaf class.
Note that composites (Menu) and leaves (MenuItem) implement operations which may not make sense (for example implementing add() method in MenuItem class) so in that case an exception might be generated. That’s why we start with the MenuComponent class which is rather simple:

#
abstract class MenuComponent {
	
	// Composites' methods
	public function add( $menuComponent ) {
		throw new UnsupportedOperationException();
	}

	public function remove( $menuComponent ) {
		throw new UnsupportedOperationException();
	}

	public function getChild( $index ) {
		throw new UnsupportedOperationException();
	}

	// Leaves and composites' methods
	public function getName() {
		throw new UnsupportedOperationException();
	}

	public function getDescription() {
		throw new UnsupportedOperationException();
	}

	public function getPrice() {
		throw new UnsupportedOperationException();
	}

	public function isVegetarian() {
		throw new UnsupportedOperationException();
	}

	public function doPrint() {
		throw new UnsupportedOperationException();
	}
}

And then our new MenuItem class looks like this:

#
class MenuItem extends MenuComponent {
	// properties here ($name, $description, $vegetarian, $price)

	// __construct(), getName(), getDescription(), getPrice() 
	// and isVegetarian() are here...

	public function getListing() {
		$result = " " . $this->getName();
		
		if( $this->isVegetarian() ) {
			$result .= "(v)";
		}

		$result .= ", " . $this->getPrice();
		$result .= "     -- " . $this->getDescription() . "\n";

		return $result;
	}
}

The constructor and getters don’t change at all so I removed them from the listing above. The only changes are:
the class inherits now from MenuComponent and I added getListing() method which returns a string with all information connected to the menu item. All other methods inherited from MenuComponents will throw an exception if used on MenuItem instance.

So, the Menu class is slightly different:

#
class Menu extends MenuComponent {
	// properties here ($menuComponents, $name, $description)

	// __construct(), getName(), getDescription() are here...

	public function add( $menuComponent ) {
		$this->menuComponents[] = $menuComponent;
	}
	
	public function getChild( $index ) {
		return $this->menuComponents[ $index ];
	}

	public function getListing() {
		$result = "\n" . $this->getName();
		$result .= ", " . $this->getDescription() . "\n";
		$result .= "---------------------------------\n";

		$iterator = new ArrayIterator( $this->menuComponents );
		while( $iterator->valid() ) {
			$menuComponent = $iterator->current();
			$iterator->next();

			if( !is_null( $menuComponent ) ) {
				$result .= $menuComponent->getListing();
			}
		}

		return $result;
	}
}

It has less properties (and getters) but one of the properties is very important: $menuComponents. Within it Menu stores all its children. This class overwrites methods connected to children operations: add(), getChild(). We don’t want now the functionality of removing, so we just not overwrite the method here (it’ll throw an exception from MenuComponent class).

And this is the place (getListing() method of Menu class) where we use learnt earlier iterators. Thanks to the fact that we iterate through aggregates with Menu and MenuItem instances and they both implement print() method we’re sure the code is solid and does what we want — it prints all elements: menus and menus’ items.

Our client’s code (Waitress) class gets simplified as well:

#
class Waitress {
	private $allMenus;

	public function __construct( $allMenus ) {
		if( !$allMenus instanceof MenuComponent ) {
			throw new InvalidArgumentException();
		}

		$this->allMenus = $allMenus;
	}

	public function printMenu() {
		$menu = $this->allMenus->getListing();
		echo $menu;
	}
}

We don’t need the method which we pass menus’ iterator to. All we need is to recursively get all menus listed by calling getListing() on the top element and then print its results on the screen.

And this is the end of our refactoring. The chapter in the book continues with explaining why the design principle learnt in the same chapter wasn’t followed this time. Surely, the composite pattern manages hierarchy and it performs specific operations related to leaves. Of course this is a phenomenon which happens quite often in software development — classic case of tradeoff. We can say Signle Responsibility design principle is being trade for transparency. Transparency which makes the client treat leaves and composites uniformly. An example composite application can be as always downloaded here.

Other examples

Nice example of composite pattern is described by Craig Sefton on his blog. Craig describes how to use the pattern to be able to create not only one-level-flat lists from our real life.
Basically, that was my thought that composite is a great way to handle complex lists. And what are lists used for on the Internet? Menus! Probably there are lots of menu implementations using composite pattern. Maybe I’ll check it later :P

However, not only such simple components as menus can be handled by composites. Few years ago I learnt that Symfony 1.4 used decorator pattern for their views system. While looking for examples of composite pattern usages I’ve found very nice articles by Alejandro Gervasio. He describes there the mentioned way but also the other way: using composite design pattern to create view system! :)
Mentioning Symfony and more complex systems build with composite pattern, Hugo Hamon, presented practical usage of design patterns during this year PHP Benelux. You can see on his presentation composite used to build form builder.

I think these examples proves how useful the composite design pattern is. Sometimes, we have to make this tradeoff in favor of transparency.

Other design patterns

Here is the list of described by me design patterns:

Permanent link to this article: https://blog.lukaszewski.it/2013/11/19/design-patterns-composite/

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>