Favoring Delegation over Inheritance

Favor object composition over class inheritance

Object composition is an alternative to inheritance. However, they point to a very precise kind of inheritance that causes most of the problems they’re talking about. For example, suppose we have a car object and we want a navigation system for it. The approach that GoF is concerned about is where the developer creates a subclass of the car object to include a navigation system or create a navigation subclass with added car functionality. Figure 1 shows the approach to inheritance they argue leads to tight coupling:

Figure 1: Inheritance solutions to adding navigation

Briefly stated, composition is using other objects but not through inheritance. The Gang of Four explain composition thusly (p.19),

New functionality is obtained by assembling or composing objects to get more complex functionality. Object composition requires that the objects being composed have well-defined interfaces.

In the case of the Window example with composition, the Window uses a Rectangle rather than being a rectangle. GoF use the terminology has-a in contrast to is-a. A subclass is-a parent class (i.e., inherits its properties) while with composition, a single class (object) has-a (or even uses-a) different class (object) for additional functionality.

Extreme Composition: Delegation

Delegation is considered an extreme example of composition (p 21 GoF), and three patterns depend on it: State, Visitor, and Strategy.

The purpose of delegation is to make composition as strong as inheritance for reuse. To do this, delegation requires two objects to handle a request. A receiving object receives a request and delegates operations to its delegate. The delegates are made up of concrete strategies in the Strategy pattern.

One way to look at the Strategy pattern is that the Client makes a request, the Context receives it and then delegates it to the ConcreteStrategy that provides the requested operational details. In some cases that will suffice to understand both delegation and the Strategy pattern. However, because GoF point to delegation specifically as a way to provide the same richness of content as inheritance, I think it deserves a bit more attention.

From Inheritance to Delegation

To get a different perspective on delegation, I started with a typical inheritance situation. Also, the request is coming from an object that uses the functionality as part of a more realistic object rather than a class I name Client.

To begin, consider the following Auto object:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

package
{
	import flash.display.Sprite;
 
	public class Auto extends Sprite
	{
		protected const BODY:Array=new Array("Steel","lights","windows","doors","horn");
		protected const INTERIOR:Array=new Array("Seats","console","steering wheel","seat belts","air bags");
		protected const ENGINE:Array=new Array("Pistons","cam shaft","valves","gears","block");
 
		public function Auto()
		{
			honkHorn();
			openWindows();
		}
 
		protected function honkHorn()
		{
			trace(BODY[4]+": Toot, toot");
		}
 
		protected function openWindows()
		{
			trace(BODY[2]+": Whosh, whosh");
		}
	}
}

The Array objects set up as constants represent a set of properties for an automobile. The two methods represent behaviors that may be related to those properties. Focus on the properties and methods simply as features that are inherited by any child class.

Next, add a GPS navigation system using inheritance:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package
{
	public class AutoWithGPS extends Auto
	{
		public function AutoWithGPS()
		{
			gps();
		}
 
		protected function gps()
		{
			trace(INTERIOR[1]+": Follow the map on the screen");
		}
	}
}

When you test it, you can see that it acts like a typical subclass. It inherits the Auto properties represented by the use of INTERIOR[1]. It also toots the horn and opens the windows; two methods that are part of the parent class methods fired off in the constructor. So we can point to some re-usability in the design.

Suppose we wanted to use the auto GPS with an airplane? Or a boat? Airplane bodies are made of aluminum, and it would inherit the auto’s steel body; so we couldn’t use it for an airplane in this configuration. A boat with a steel body? Maybe. Big ships are made of steel, but small boats might go to the bottom with a steel body. We’d need to be careful with boats.

As we add more subclasses the dependencies pile up and our options become fewer and fewer. Now, let’s start with the Auto class and use delegation to adde GPS.

Begin by saving the original Auto class as AutoDelegate.as in the same folder with the Strategy example from Part 2 of this series. The listing below, adds GPS using delegation. The class still has all of the properties and methods of the Auto class without adding those properties to the GPS functionality. Also using either Flex or Flash, be sure to change the class to call, AutoDelegate.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

package
{
	import flash.display.Sprite;
 
	public class AutoDelegate extends Sprite
	{
		protected const BODY:Array=new Array("Steel","lights","windows","doors","horn");
		protected const INTERIOR:Array=new Array("Seats","console","steering wheel","seat belts","air bags");
		protected const ENGINE:Array=new Array("Pistons","cam shaft","valves","gears","block");
 
		public function AutoDelegate()
		{
			honkHorn();
			openWindows();
			getGPS();
		}
 
		protected function honkHorn()
		{
			trace(BODY[4]+": Toot, toot");
		}
 
		protected function openWindows()
		{
			trace(BODY[2]+": Whosh, whosh");
		}
 
		protected function getGPS()
		{
			var gps:Context=new Context(new StratGPS());
		}
	}
}

Now, could we re-use the StratGPS object in an airplane or boat? Sure, it’s not dragging all of the auto’s baggage. We’re not bringing the steel body, horn or windows. We’re just delegating the GPS duties to the StratGPS concrete strategy.

In the above listing, the request is sent by the AutoDelegate object through the getGPS method. The getGPS() operation is a simple instantiation of a Context object that specifies which concrete context is required.

I hope this begins to shed some light on delegation. The Gang of Four seem to be very particular about what counts as delegation as opposed to just object composition. The acid test of true delegation is when an object passes along a reference to itself when passing along a request. The Context class does this. Because delegation can be tricky, the Gang of Four suggest that you use it in highly stylized ways. What (you may well ask…) is a highly stylized way? Why it’s a standard design pattern that uses delegation, just like the Strategy pattern does.

Aggregate Relations

Conjoined Participants

As can be seen in the red arrow symbols in the Participant Relations diagram at the top of this post, an aggregate relation is indicated by an arrow with a diamond at its base. The GoF illustrate the relationship as shown in Figure 1:

Figure 1: Aggregator and Aggregatee

The Aggregator creates an aggregate instance of the Aggregatee. As noted, GoF point out that no single code set can demonstrate what an aggregate relationship looks like, but I think that we can get a start by looking at a fairly simple relationship in the State design I created so that we could discuss both aggregate relations and delegation. (The Strategy design also provides a good example of aggregation with delegation.)

In looking at the aggregate relations between the Context class and State interface in the State example, we see the following aggregation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class Context
	{
		private var stoph:State;
		private var moveup:State;
		private var movedown:State;
		private var moveleft:State;
		private var moveright:State;
		private var stateNow:State;
		public var chopper:Sprite;
 
		public function Context( chopper:Sprite )
		{
			this.chopper=chopper;
			trace("State is here");
			moveup=new MoveUp(this);
			stoph=new Stop(this);
			movedown=new MoveDown(this);
			moveleft=new MoveLeft(this);
			moveright=new MoveRight(this);
			stateNow=stoph;
		}
		public function upMove():void
		{
			stateNow.doMoveUp();
		}
...end snippet

So what’s getting aggregated? In this instance the entire State interface and all of its implementations (classes) and methods are aggregated in the Context class. All of the requests coming from the Client are delegated to the State through such aggregation.

At this point you may better understand GoF’s statement,

Aggregation implies that an aggregate object and its owner have identical lifetimes.

The aggregate object is that created in the Context and the owner is the State interface and implementations. The Context creates the aggregate object by gathering up all of the concrete states. When the Client makes a request, it uses an instance of the Context:

private var contextNow:Context=new Context(chopper);

The instance, contextNow, essentially is the aggregate object. If you change the State implementations, it doesn’t matter because the Client makes the requests through the Context that creates an aggregate instance. That means if you change the implementations of the concrete States, everything still works because the requests are all through the Context class. As long as an aggregate relationship exists between participants in a design pattern, the aggregator creates an aggregate instance. With requests made through the aggregator, you decouple the request and the objects that carry out the requests. Further, through aggregation you can reuse objects all you want arranged in the way you want to employ them.

Closely Related Participants

You will find aggregate relationships in several design patterns, and the actual ActionScript 3.0 encoded aggregation has many faces. In coming to understand aggregation, take a look at several of the following classes that contain aggregation relationships.

• Builder
• Bridge
• Composite
• Decorator
• Flyweight
• Command
• Interpreter
• Memento
• State
• Strategy

One of the more interesting uses of aggregation is where the child classes aggregate the parent class or interface. You can see this in the Composite and Decorator patterns. Likewise, you will see many different ways that the aggregation process is designed to structure the relationships between design pattern participants. By looking at the code in different examples aggregation you will begin to see what aggregation means.

Aggregation for Change

After posting the State example with the Helicopter (extension of Sprite class) jumping around the screen, we received several comments on improving the design. By having a State design pattern in place, that should not be too difficult to change the states for the Helicopter. The structure can remain the same, but not only could we substitute just about any sprite for the Helicopter, we could change the algorithms using the current interfaces without touching the fundamental design pattern. So in the next post, we’ll look at the Helicopter movement with an eye to making it more state-like while maintaining the current structure, even adding helper classes if we want. As always, we value your comments.

Class Relations

UML Controversy: Tempest in a Teapot

In this and subsequent posts, I’m sticking with the notations used by GoF. If you’re into UMLs, you’ll know that GoF actually use a few non-standard notations, but I think that by using the ones GoF use our discussion will be less confusing. If you’re interested in a more standardized UML notation take a look at Judith Bishop’s book, C# 3.0 Design Patterns (O’Reilly) on pp.4-5.

GoF discuss abstract classes and interfaces as interfaces. So, in an example where an abstract class is used, you’ll see an italicized class name. If an interface is used, you’ll see the same thing. In some respects this can be quite helpful in that when you see any italicized text in a class diagram you’ll think interface and know that you can develop your own design pattern using either an abstract class or interface.

The inheritance symbol, that we’ll be covering in detail in a later post, is used to denote both inheritance (extends) and implementation (implements). This is consistent with GoF’s interchangable use of abstract classes and interfaces and their notations. So bear with me on these idiosyncrasies and help focus on the relationships between participants.

Let’s Get Acquainted

When one class holds a reference to another class, we can represent that by a line with an arrow pointing to the class that it has the reference to as shown in the Participant Relations diagram between Class A and the Interface/Abstract Class. If one class holds a reference to many objects in another class, a solid circle is placed at the tip of the arrow as shown between Class D and Class E.

That’s easy enough to see, but the real question is What’s going on? In other words, why would one class hold a reference to another? The answer lies at the core of Design Patterns: reuse. Class A is using the the Interface/Abstract class in some manner shape or form. Instead of creating its own interface, it’s reusing another one.

If you can remember that, you’re 90% of the way to understanding Design Patterns. You may recall the second principle of Design Patterns is

Favor object composition over class inheritance.

The relationship indicates that Class A has an interface. It doesn’t implement the interface, but through composition has the interface. Such a relationship is an acquaintance one. That means it has reused an existing object through composition.

In code, an acquaintance relationship can be many things. For example, consider the Prototype pattern covered in this blog. In this pattern the Client asks a prototype to clone itself. The pertinent code looks like this:

private var tDog:Prototype;
tDog = new Dog();
cDog = tDog.clone(tDog);

You may be thinking, That code creates an instance of the Dog class. Shouldn’t that be a creates relationship? If you look closely, you will see that it does not create an instance of Prototype but rather of Dog. The acquaintance arrow points to the Prototype interface; so, while it does instantiate a class, it is through the acquaintance with Prototype and not directly with Dog.

At this point, it’s very easy for the satellite to spin out of orbit when it comes to differentiating between an object reference and the creation of one class by another. However, as you look at more and more implementations of design patterns in code, you’ll see that where you have an acquaintance relationship, you’ll find that one class is using the other class through composition and not just creation. Using composition allows one class to incorporate the interface of another class and use its properties and methods. To use those properties and methods, the class that has another class through composition needs some kind of instantiation.

Think Composition

A lot of problems understanding participant relations in design patterns can be solved if you keep this in mind: Both inheritance and composition reuse a class interface. When you think composition, you almost force your code into good OOP. If you don’t use composition, what are your alternatives?

1. A big sequential program where you put all of your operations into one huge file. (Bad)
2. A big procedural program where call procedures as needed in one huge file. (Not good)
3. A big mother of all classes that spawns subclasses like of black widow laying thousands of eggs. (Scary)

Composition is favored because it is more flexible:

Composition is where, new functionality is obtained by assembling or composing objects to get more complex functionality.

I use the term flexible in this context to mean that composition is defined dynamically at run-time and helps keep each class encapsulated and to focus on its single task. Think of this—salt and pepper. Salt has one function and pepper has another. In composition you can select one or the other or both. With inheritance from class Spices, the salt and pepper may get mixed together, which may be fine and save time in some instances. However, sometimes you just want one or the other. You want each encapsulated and you want them when you need them; not cooked into the meal where you may get too much of one or the other or both.

Delegation

Delegation is a way to get the most out of composition. So, What’s delegation? According to Gamma, Helm, Johnson and Vissides, delegation requires two objects to handle a request. A receiving object delegates operations to its delegate. For an example of where delegation is used extensively, take a look at the Visitor design pattern. The operations performed on the concrete elements are always delegated to a Visitor object. When using delegation, a request to an object is forwarded to a delegate instead of by the object using an inherited operation. By using delegation, you can see that it makes it easy to compose behaviors at run-time and to change the way they’re composed. (When we discuss aggregate relations, you’ll hear more about delegation.)

Many References

In some patterns like the Observer (Chapter and Visitor, you will see the acquaintance arrow with the solid circle on the end. That means one object maintains many references another object. In looking at the discussion of the Visitor pattern, you can see the ObjectStructure class holds many references to the Element interface. Such multiple references are often handled by Array and Vector objects. For example, in the Visitor post, you will see:

1
2
3
4
5
6
7

//From ObjectStructure class
private var elements:Array=[];
 public function attach(element:IElement ):void
 {
          elements.push(element);
 }
....

That sets up the acquaintance between the ObjectStructure and the Element interface. Because it is a reference to an Array object, it holds a reference to all of its elements as well.

Where to Find Acquaintance Relations in Design Patterns

Of the 23 patterns in the Design Pattern catalog, only 7 have acquaintance relations separate from Client requests. They are:

1. Proxy
2. Adapter (Object version only)
3. Chain of Responsibility (Self-reference to Handler interface)
4. Command
5. Mediator
6. Observer
7. Visitor

The great majority of acquaintance relations in class diagrams are between the Client class and one of the design pattern participants. Some, like the Abstract Factory and Flyweight , have multiple acquaintance relations between the Client and other participants. Also, if you look at Client relations, you will see that they are primarily through an interface and not through concrete classes. (The Flyweight is an exception and the Visitor and Interpreter are partial exceptions.)

In the next post covering Design Pattern relations, we’ll look at aggregate relations and see how they compare to the ubiquitous acquaintance relations. By comparing them, we can better understand them both and what role each plays in the different design patterns.