It is natural to think of objects as containing other objects. For example, a computer is an object. A computer is also comprised of other objects, such as a motherboard, keyboard, and hard drives. A motherboard is an object, but is too is also composed of other objects, such as a processor, video card, and ram. Objects are often built, or composed, or other objects. This concept is known as composition (Weisfeld, 2000).

When we discuss inheritance, we talk about inheritance as an “Is-a” relationship. Where a Border Collie is a dog. When we talk about composition, we use the “Has-a” relationship to describe it. A computer is an object, and it has a motherboard, and it has a keyboard. The motherboard and the keyboard are both objects. A computer is obviously not a motherboard, nor a keyboard.

Using composition combines systems in much less complex parts. In everyday situations, we find it easier to communicate and associate with more abstract concepts, such as a car. Instead of referring to the car as a large unit with tires, a steering wheel, engine, and so forth, we associate it as an object composed of several smaller objects. Many of us approach problem solving in the same fashion.

Composition is important in software design because it represents modularity and essentially reuse. The computer object may have a monitor. That monitor can be swapped out with many different types of monitors. It does not matter which monitor goes with which computer.

When we design objects, we like to be able to swap out components easily. Our classes, which may be comprised of other objects, should reference the more abstract interfaces. For example, consider our computer object. Our computer object should contain a keyboard, perhaps an abstract keyboard class, or a keyboard interface as a reference. We would not want to associate our computer object with a more specific keyboard, such as an ergonomic keyboard, because this creates a dependency on our computer class with a specific keyboard reference. If we associate our computer with a more generalized type of keyboard, we can use polymorphism to handle the more specific types of keyboards, such as a wireless keyboard, or a touchpad.

Computer computer = new Computer();
computer.Keyboard = new ErgonomicKeyboard();

If we want to change our keyboard type, we can, without affecting the computer object, because the computer object only cares about a keyboard, not a specific instance of a keyboard. How we associate our composed objects with our computer is a matter of design choice. For instance, we can choose to inject all of our dependencies into our constructor, such as the following example. This is known as dependency injection, and it will not be covered in this document.

Computer computer = new Computer(Keyboard, Motherboard, Monitor);

The main point is that we can design our classes in many ways to leverage the modularity of our components, reusing objects as much as possible.

Other Advantages of Composition

Another advantage to composition is that systems can be built and maintained independently from smaller subsystems. Since our objects are composed of other objects, those objects can be created separately and independently. This forms the basis of functional decomposition, a process which is familiar to software development. Typically, we build software systems using independent components. The smaller the system, the easier it is to maintain. If our DVD drive should break, we can locate the source of the problem more easily than in an integrated system where the parts are not as easily decomposable.

Composition promotes another good practice, testability. In a larger system, using our computer example, we can put tests in place to maintain the integrity of each component. As we add new components to the system, we test that the others still function properly. In our computer example, if our DVD drive should break, we can remove it from the system to have it fixed. If the computer system were a single unit, we would need to repair the entire system, which is much more timely and costly.

Types of Composition

There are two types of composition, association and aggregation. Both forms adhere to the “has-a” relationship seen in composition. “An aggregation is a complex object composed of other objects. An association is used when one object wants another object to perform a service for it” (Weisfeld, 2000). Depending on how we perceive the relationship of these objects, we can choose to classify them as aggregations or associations.

Aggregation implies that a complex object is composed of other objects. For example, a computer is made up of a motherboard, keyboard, and monitor. We have seen this example mentioned above. With aggregation, we tend to see the whole before we see the components that comprise it. We think of a computer as a computer, and not as a motherboard, keyboard, and monitor. We think of a car as a car, and not as a large unit containing tires, an engine, a steering wheel, et cetera.

Association is where relationships exist between objects because one object needs the other to perform a service for it. For example, our computer is made up of a keyboard, mouse, and monitor. These are each separate objects, and that is aggregation. The computer delegates some of its work to the mouse, some to the keyboard, and some to the monitor. The computer needs the services of these objects to work, since it cannot provide these capabilities by itself. This relationship is association.

When using aggregation and association, there is often no one right answer when design decisions are made. There is a gray area that separates the two concepts. In our computer example, some of our associations also contain aggregations, and vice versa. This may be the case time and time again in the real world.

Favor Composition Over Inheritance

One principle of object-oriented design mentioned by the Gang of Four is, “Favor object composition over class inheritance.” By nature, inheritance is brittle. This is true because derived classes inherit behavior by sub-classing, and that behavior is set statically at compile time. All derived classes must inherit the same behavior.

Composition increases system flexibility. If we use composition, we can extend an object’s behavior dynamically, at runtime, adding new responsibilities to objects that we may not have thought about during design time. Another benefit of this technique is that we do not need to change existing code, and so the chances of introducing new bugs or unwanted effects are reduced.

For more on composition versus inheritance...

References:

Weisfeld, M. (2000). The Object-Oriented Thought Process (1st ed.). Indianapolis, IN: Sams Publishing.