Object-Oriented Design – Inheritance, Composition, and Protocols in Objective-C

compositiondesigninheritanceobject-orientedobjective c

I'm reading a book on general object oriented concepts to try and gain a solid understanding of everything. One thing that is throwing me off is the difference between Inheritance and Composition. I know that in terms of Inheritance, it is "is-a" with the subclass. Such as an Employee class inherits from the Person class, because an employee "is-a" person. Composition's subclass is "has-a". For example, a Car class inherits from the Steering Wheel class because the car "has-a" steering wheel.

Cool, so far. But… isn't this still inheritance? I understand the difference between "is-a" and "has-a". I also understand that Composition is basically combining multiple classes to make another class that contains all of those objects. I have two questions:

  1. Isn't composition still a form of inheritance in some ways?
  2. Typing this out, I may have answered my own question. In Objective-C, we use Protocols to specify what needs to be inherited and what is optional. Is simply throwing a protocol into the header what differentiates Inheritance and Subclassing? Do we use protocols in both inheritance and composition?

I understand the difference quite well, and know how to utilize each through my programs. I guess it's just a question regarding semantics, if composition is really a form of inheritance or not.

Best Answer

No, the two concepts are different.

A better car analogy would be regarding the engine. Let us assume we have an interface for an engine. It might have properties such as number of cylinders and RPM. You might be able to invoke behavior such as opening and closing the throttle. However, this is just an interface: engine is not an implementation. The Car class has-a engine: when you construct a car, you install something that implements that engine interface. Many cars have different engines as options.

Now there is the implementation. Perhaps we define a SixCylinderEngine class. It is-a engine because it implements that interface. It can be used anywhere the engine interface is used.

But wait! Some people want a supercharged version of the engine. This is not as simple as changing a variable in the existing engine, this is a major change. Different parts, a second drive belt, another major component (the supercharger), more horsepower, etc.

One way to accomplish this would be to subclass SixCylinderEngine and add in the supercharger. That has merit, but can introduce complex interdependencies between the subclass and superclass. That would be another is-a relationship.

Instead, we define a SuperchargedSixCylinderEngine class that implements Engine directly (is-a). In order to reuse code, it contains a SixCylinderEngine internally and delegates certain functions (has-a).

From here, the next step is to have a SuperchargedEngine which accepts any engine: 6, 8, 10 cylinder, anything you want.

Here is a code example of the difference.

Inheritence:

public int getHorsepower() {
  return 1.4 * super.getHorsepower();
}

Composition:

private Engine engine;

public SuperchargedEngine(Engine e) {
  engine = e;
}

public int getHorsepower() {
  return 1.4 * engine.getHorsepower();
}
Related Topic