"Prefer composition over inheritance" - Is the only reason to defend against signature changes?

Question

This page advocates composition over inheritance with the following argument (rephrased it in my words):

A change in the signature of a method of the superclass (which hasn't been overridden in the subclass) causes additional changes in many places when we use Inheritance. However, when we use Composition, the required additional change is only at a single place: The subclass.

Is that really the only reason to favor composition over inheritance? Because if that's the case, this problem can be easily alleviated by enforcing a coding style which advocates overriding all methods of the superclass, even if the subclass does not change the implementation (that is, putting dummy overrides in the subclass). Am I missing something here?

Answer 1

I like analogies so here's one: Have you ever seen one of those TVs that had a VCR player built-in? How about the one with a VCR and a DVD player? Or one that have a Blu-ray, DVD and VCR. Oh and now everyone is streaming so we need to design a new TV set...

Most likely, if you own a TV set, you don't have one like the above. Probably most of those have never even existed. You most likely have a monitor or set that has numerous inputs so that you don't need a new set every time there is a new type of input device.

Inheritance is like the TV with the VCR built-in. If you have 3 different types behaviors you want to use together and each has 2 options for implementation, you need 8 different classes in order to represent all of those. As you add more options the numbers explode. If you use composition instead, you avoid that combinatorial problem and the design will tend to be more extensible.

Answer 2

Normally the driving idea of Composition-Over-Inheritance is to provide greater design flexibility and not to reduce the quantity of code you need to change to propagate a change (that I find questionable).

The example on wikipedia give a better example of the power of his approach:

Defining a base interface for each "composition-piece" you could easy create various "composed-object" with a variety that could be difficult to reach with inheritance alone.

Answer 3

No, it is not. In my experience composition over inheritance is a result of thinking about your software as a bunch of objects with behaviours that talk to each other / objects providing services to each other instead of classes and data.

This way, you have some objects that provide serviecs. You use them as building blocks (really pretty much like Lego) to enable other behaviour (e.g. a UserRegistrationService uses the services provided by an EmailerService and a UserRepository).

When building larger systems with this approach i naturally used inheritance in very few cases. At the end of the day inheritance is a very powerful tool that should be used with caution and only where appropriate.

Answer 4

"Prefer composition over inheritance" is just a good heuristic

You should consider the context, as this is not a universal rule. Do not take it to mean never use inheritance when you can do composition. If that were the case, you would fix it by banning inheritance.

I hope to make this point cleared along this post.

I will not try to defend the merits of composition by itself. Which I consider off topic. Instead, I will talk about some situations when developer may consider inheritance that would be better using composition. On that note, inheritance has its own merits, which I also consider off topic.

---

Vehicle example

I am writing about developers who tries to things the dumb way, for narrative purposes

Let us go for a variant of the classical examples that some OOP courses use… We have a Vehicle class, then we derive Car, Airplane, Balloon and Ship.

Note: If you need to ground this example, pretend these are kinds of objects in a video game.

Then Car and Airplane may have some common code, because they both can roll on wheel on land. The developers may consider creating an intermediary class in the inheritance chain for that. Yet, actually there is also some shared code between Airplane and Balloon. They could consider creating another intermediary class in the inheritance chain for that.

Thus, the developer would be looking for multiple inheritance. At the point where the developers are looking for multiple inheritance, the design has already gone wrong.

It is better to model this behavior as interfaces and composition, so we can reuse it without having to run into multiple class inheritance. If the developers, for example, create the FlyingVehicule class. They would be saying that Airplane is a FlyingVehicule (class inheritance), but we could instead say that Airplane has a Flying component (composition) and Airplane is a IFlyingVehicule (interface inheritance).

Using interfaces, if necessary, we can have multiple inheritance (of interfaces). In addition, you are not coupling to a particular implementation. Increasing reusability and testability of your code.

Remember that inheritance is a tool for polymorphism. In addition, polymorphism is a tool for reusability. If you can increase the reusability of your code by using composition, then do so. If you are not sure whatever or not composition provides better reusability, "Prefer composition over inheritance" is a good heuristic.

All that without mentioning Amphibious.

In fact, we may not need things that go off the ground. Stephen Hurn has a more eloquent example in his articles “Favor Composition Over Inheritance” part 1 and part 2.

---

Substitutability and Encapsulation

Should A inherit or compose B?

If A Is an specialization of B that should fulfil the Liskov substitution principle, inheritance is viable, even desirable. If there are situations where A is not a valid substitution for B then we should not use inheritance.

We might be interested in composition as a form of defensive programming, to defend the derived class. In particular, once you start using B for other different purposes, there may be pressure to change or extend it to be more suitable for those purposes. If there is the risk that B may expose methods that could result in an invalid state in A we should be using composition instead of inheritance. Even if we are the author of both B and A, it is one thing less to worry about, therefore composition eases the reusability of B.

We may even argue that if there are features in B that A does not need (and we do not know if those features could result in an invalid state for A, either in the present implementation or in the future), it is a good idea to use composition instead of inheritance.

Composition also has the advantages of allowing switching implementations, and easing mocking.

Note: there are situations where we want to use composition despite the substitution being valid. We archive that substitutability by using interfaces or abstract classes (which one to use when is another topic) and then use composition with dependency injection of the real implementation.

Finally, of course, there is the argument that we should use composition to defend the parent class because inheritance breaks the encapsulation of the parent class:

Inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'

-- Design Patterns: Elements of Reusable Object-Oriented Software, Gang of Four

Well, that is a poorly designed parent class. Which is why you should:

Design for inheritance, or prohibit it.

-- Effective Java, Josh Bloch

---

Yo-Yo problem

Another case where composition helps is the Yo-Yo problem. This is a quote from Wikipedia:

In software development, the yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program.

You can resolve, for example: Your class C will not inherit from class B. Instead your class C will have a member of type A, which may or may not be (or have) an object of type B. This way you will not be programming against the implementation detail of B, but against the contract that the interface (of) A offers.

---

Counter examples

Many frameworks favor inheritance over composition (which is the opposite of what we have been arguing). Developer may do this because they put a lot of work into their base class that having it implemented with composition would have increase the size of the client code. Sometimes this is due to limitations of the language.

For example, a PHP ORM framework may create a base class that uses magic methods to allow writing code as if the object had real properties. Instead the code handled by the magic methods will be going to the database, query for the particular requested field (perhaps cache it for future request) and return it. Doing it with composition would require the client to either create properties for each field or write some version of the magic methods code.

Addendum: There some other ways one could allow extending ORM objects. Thus, I do not think inheritance is necessary on this case. It is cheaper.

For another example, a video game engine may create a base class that uses native code depending on the target platform to do 3D rendering and event handling. This code is complex and platform specific. It would be expensive and error prone for the developer user of the engine to deal with this code, in fact, that is part of the reason of using the engine.

Furthermore, without the 3D rendering part, this is how many widget frameworks work. This releases you from worrying about handling OS messages… in fact, in many languages you cannot write such code without some form of native biding. Moreover, if you were to do it, it would tight your portability. Instead, with inheritance, provided the developer do not break compatibility (too much); you will be able to easily port your code to any new platforms they support in the future.

In addition, consider that many times we only want to override a few methods and leave everything else with the default implementations. Had we been using composition we would have to create all those methods, even if only to delegate to the wrapped object.

By this argument, there is a point where composition can be worst for maintainability than inheritance (when the base class is too complex). Yet, remember that maintainability of inheritance can be worse than that of composition (when the inheritance tree is too complex), which is what I refer to in the yo-yo problem.

In the presented examples, the developers rarely intend to reuse the code generated via inheritance in other projects. That mitigates the diminished reusability of using inheritance instead of composition. In addition, by using inheritance the framework developers can provide a lot of easy to use and easy to discover code.

---

Final thoughts

As you can see, composition has some advantage over inheritance in some situations, not always. It is important to consider the context and the different factors involved (such as reusability, maintainability, testability, etc…) to make the decision. Back to the first point: "Prefer composition over inheritance" is a just good heuristic.

You may also have notices that many of the situation I describe can be resolved with Traits or Mixins to some degree. Sadly, these are not common features in the great list of languages, and they usually come with some performance cost. Thankfully, their popular cousin Extension Methods and Default Implementations mitigate some situations.

_{I have a recent post where I talk about some of the advantages of interfaces in why do we require interfaces between UI,Business and Data access in C#. It helps decoupling and eases reusability and testability, you might be interested.}

Answer 5

The line: "Prefer composition over inheritance" is nothing but a nudge in the right direction. It's not going to save you from your own stupidity and actually gives you a chance to make things much worse. That's because there is a lot of power here.

The main reason this even needs to be said is because programmers are lazy. So lazy they will take any solution that means less keyboard typing. That is the main selling point of inheritance. I type less today and some someone else gets screwed tomorrow. So what, I wanna go home.

Next day the boss insists I use composition. Doesn't explain why but is insisting on it. So I take an instance of what I was inheriting from, expose an interface identical to what I was inheriting from, and implement that interface by delegating all work to that thing I was inheriting from. It's all brain dead typing that could have been done with a refactoring tool and seems pointless to me but the boss wanted it so I do it.

Next day I ask if this is what was wanted. What do you think the boss says?

Unless there was some need to be able to dynamically (at run time) change what was being inherited from (see state pattern) this was a huge waste of time. How can the boss say that and still be in favor of composition over inheritance?

In addition to this not doing a thing to prevent breakage due to method signature changes this entirely misses the biggest advantage of composition. Unlike inheritance you are free to make a different interface. One more appropriate to how it'll be used at this level. You know, abstraction!

There are some minor advantages to automatically replacing inheritance with composition and delegation (and some disadvantages) but keeping your brain turned off during this process is missing a huge opportunity.

Indirection is very powerful. Use it wisely.

Answer 6

Here is another reason: in many OO languages (I am thinking of ones like C++, C# or Java here), there is no way to change the class of an object once you've created it.

Suppose we're creating an employee database. We have an abstract base Employee class, and start to derive new classes for specific roles - Engineer, Security Guard, Truck Driver and so on. Each class has specialised behaviour for that role. Everything is good.

Then one day an Engineer gets promoted to Engineering Manager. You can't re-class an existing Engineer. Instead, you have to write a function that creates an Engineering Manager, copying all the data from the Engineer, deletes the Engineer from the database, then adds the new Engineering Manager. And you have to write such a function for each possible role change.

Even worse, suppose a Truck Driver goes on long-term sick leave, and a Security Guard offers to do Truck Driving part time to fill in. You now have to invent a new Security Guard And Truck Driver class just for them.

It makes life so much easier to create a concrete Employee class, and treat it as a container to which you can add properties, such as the job role.

Answer 7

Inheritance provides two things:

1) Code-reuse: Can be accomplished easily through composition. And in fact, is better achieved through composition as it better preserves encapsulation.

2) Polymorphism: Can be accomplished through "interfaces" (classes where all methods are pure-virtual).

A strong argument for using non-interface inheritance, is when the number of methods required is large and your subclass only wants to alter a small subset of them. However, in general your interface's should have very small footprints if you subscribe to the "single-responsibility" principle (you should), so these cases should be rare.

Having the coding style requiring overriding all parent class methods doesn't avoid writing a large number of pass-through methods anyways, so why not re-use code through composition and get the added benefit of encapsulation? Plus, if the super-class were to be extended by adding another method, the coding style would require adding that method to all sub-classes (and there's a good chance we're then violating "interface segregation"). This problem grows quickly when you start having multiple levels in inheritance.

Finally, in many languages unit testing "composition" based objects is much easier than unit testing "inheritance" based objects by substituting the member object with a mock/test/dummy object.

Answer 8

Is that really the only reason to favor composition over inheritance?

Nope.

There are many reasons to favor composition over inheritance. There isn't a single correct answer. But I'll throw another reason to favor composition over inheritance into the mix:

Favoring composition over inheritance improves the readability of your code, which is very important when working on a large project with multiple people.

Here's how I think about it: when I'm reading somebody else's code, if I see that they've extended a class, I'm going to ask what behavior in the super class are they changing?

And then I'll go through their code, looking for an overriden function. If I don't see any, then I classify that as a misuse of inheritance. They should have used composition instead, if only to save me (and every other person on the team) from 5 minutes of reading through their code!

Here's a concrete example: in Java the JFrame class represents a window. To create a window, you create an instance of JFrame and then call functions on that instance to add stuff to it and show it.

Many tutorials (even the official ones) recommend that you extend JFrame so you can treat instances of your class as instances of JFrame. But imho (and the opinion of many others) is that this is a pretty bad habit to get into! Instead, you should just create an instance of JFrame and call functions on that instance. There is absolutely no need to extend JFrame in this instance, since you aren't changing any of the default behavior of the parent class.

On the other hand, one way to perform custom painting is to extend the JPanel class and override the paintComponent() function. This is a fine use of inheritance. If I'm looking through your code and I see that you've extended JPanel and overrided the paintComponent() function, I'll know exactly what behavior you're changing.

If it's just you writing code by yourself, then it might be just as easy to use inheritance as it is to use composition. But pretend you're in a group environment and that other people will be reading your code. Favoring composition over inheritance makes your code easier to read.