TO HAVE OR TO BE?

A car and a plane are vehicles so it is obvious that both of these classes should be expanded from their common base class called Vehicle. This is a typical academic example but while deciding about binding these classes with the inheritance relation, we should be aware of some consequences.

Fig. 1 Implementation of inheritance relation.

In this case the classes are closely linked to each other – this means that the changes in the behavior of every class can be achieved by making changes to the base class código. This can be an advantage as well as disadvantage – it depends on what kind of behavior we expect. If the inheritance is applied at the wrong time, the process of adding a new function may encounter some implementation difficulties because it won’t fit the created class model. We will have to choose between duplicating the code and reorganizing our model – and it can be a really time-consuming process. We can call the code that executes the inheritance relation as “open-closed” -this means that it is open for extensions but closed for modification. Assuming that in the Vehicle class there is a general, defined engine operation, of every vehicle, the moment we’d want to add an engineless vehicle (e.g. bike) model to our class hierarchy, we’d have to make some serious changes to our classes.

class Vehicle
  def start_engine
  end

  def stop_engine
  end
end

class Plane < Vehicle
  def move
    start_engine
    …
    stop_engine
  end
end

Composition

If we’re only interested in some part of the behavior of the existing class, a good alternative for inheritance is to use composition. Instead of creating subclasses that inherit every behavior (the ones we need and the ones we don’t need at all), we can isolate the functions we need, and equip our objects in references to them. In such a way, we give up the thought that object is a type of a base object, in favor of the assertion that it contains only some parts of its properties.

Fig. 2 Using the composition

Following this approach we can isolate the code that is responsible for the engine operation to the autonomous class called Engine and place reference to it only in the classes that represent vehicles with engines. Isolating the functions with the use of composition will make the Vehicle class structure simpler and will strengthen the encapsulation of individual classes. Now, the only way the vehicles can have an effect on the engine is to use its public interface, because they won’t have information about its implementation no more. What’s more, it will allow to use different types of engines in different vehicles, and even allow their exchange while the program is running. Of course, using composition is not flawless – we are creating a loosely connected class set, which can be easily extended and is open for modification. But, at the same time, each class is connected to many other classes, and must have information regarding their interfaces.

class Vehicle
end

class Engine
  def start
  end

  def stop
  end
end

class Plane < Vehicle
  def initialize
    @engine = Engine.new
  end

  def move
    @engine.start
    @engine.stop
  end

  def change_engine(new_engine)
    @engine = new_engine
  end
end

The choice

Both described approaches have advantages and disadvantages, so how to choose between them? Inheritance is a specialization, so it’s best to apply them only for problems, in which there are “is-a” type relations – so we deal with the real hierarchy of types. Because inheritance tightly links classes together, firstly, we should always consider whether to use composition or not. Composition should be applied for problems in which there are “has-a” type relations – so the class has many parts but it is something more than a set of classes. A plane consists of parts but alone it is something more – it has additional abilities, such as flight. Going further with this example, individual parts can occur in different specialist variants, and then it is a good moment to use inheritance.

Inheritance as well as composition are only tools that the programmers have at their disposal, so choosing the right tool for a particular problem requires experience. So let’s practice and learn from our mistakes 🙂