Inheritance versus composition

One of the compelling features of an OOP language is code reuse. Once a class has been created and tested, it should represent a block of code/functionality ready to be used.

The simplest way to make use of an already defined class is to just create an instance of it, but you can also place an object of that class inside a new class. The new class can bundle in any number of other object types to create the functionality required. This concept of building up a brand-new class by reusing existing ones is called association. This term is referred to as a Has-A relationship. Imagine you have a class called Desktop to represent a typical PC; a desktop has a hard disk, motherboard, and so on. We have already used this concept in previous code examples.

Association comes in two flavors. This detail is most of the time overlooked. The first type of composition is called aggregation. An aggregation represents a relationship between two or more objects in which each object has its own life cycle, and there the notion of ownership is not applicable. Basically, the object part of the relationship can be created and destroyed independently. Take the earlier example of Desktop. The computer can stop working through no fault of the hard drive. While the desktop can be thrown away, you can take the hard drive and put it in a different PC, and it will still carry on working.

Composition is the next type of association. It is a specialized type of aggregation. In this case, once the container object is destroyed, the contained objects will cease to exist as well. In the case of composition, the container will be responsible for creating the object instances. You can think of composition as the components are part of the whole, as a leg and head are part of a human:

 

Through composition, you can have a great deal of flexibility. Usually, your class member objects are private; a good encapsulation design would require you to do this. Since these objects are not accessible by the client of your class, you are at liberty to change them, either by adding or removing them, without impacting the client code at all. You can even change the runtime types to provide different runtime behaviors if the requirements demand it. For example, the runtime instance for hard disks can be either a typical hard drive or the new standard—a solid state drive.

Typically, inheritance gets a lot of focus since it is so important in object-oriented programming, and a new developer uses it everywhere. This can result in awkward and over-complicated class hierarchies. You should first consider composition when you are about to create a new class, and only if applicable should you make use of inheritance.

Another term used frequently in the OOP world is is-a. This concept is based entirely on inheritance. We have already seen inheritance; it comes in two shapes—class or interface. Furthermore, it is unidirectional (a bicycle is a vehicle but a vehicle is not a bicycle; it could be a car, for example).

Of course, there are scenarios where mixing association (whatever form it takes) and inheritance is required. Imagine you're building a class hierarchy for vehicles:

You start with a Vehicle interface, and to provide a Bicycle type you will inherit the interface and add, through composition, two references to the Wheel class.