Composition or Inheritance Followup
Some of the responses from the editorial yesterday really help clarify the question of when to use Composition or Inheritance. Here are a few of the responses I received yesterday.
Ed:
I found your brief discussion of inheritance vs composition really interesting, but I think it missed two key questions that should govern the decision.
1) At what stage of development?
2) Under what circumstances?
To elaborate briefly:
1) At what stage of development? Even with Agile development, we should be engaging in each of the activities, however briefly. It takes but a few moments to look at this in the context of OO Analysis, where we are trying to understand the domain model. Very clearly a Car is not an Engine. It fails the test of Identity – the “Is A” question. So at an analysis model level, the answer is clear – it is a Composition relationship. If that is not our conclusion, then perhaps we have the wrong classes. Do we really care about Cars, or is this an engine repair application and our inherited class is really ‘Car Engine’?
2) Under what circumstances? When we enter the steps of design and coding, the starting point should be the analysis model – so we should be starting this example expecting to use Composition. Then the circumstance question kicks in. If the language doesn’t support inheritance, we are done as we will use Composition even if the analysis model concluded it were an Inheritance relationship (‘Car Engine’ class instead of ‘Car’ class.) If the language supports inheritance, we may ask ourselves the common questions to determine if we have reason to use it instead of composition such as:
a. What assumptions are likely to change? If those assumptions change, would use of Inheritance fail?
b. Does our application ever care about vehicles that don’t have engines, or is the fact of a vehicle having an engine what makes it interesting to us?
c. Are all of the behaviors we wish to model behaviors of the Engine class, with only Properties for additional attributes of Car? Here is a case where inheritance may be a simpler and more efficient choice, if all our behavioral code would need additional pass-through methods on the Car class to use Composition, whereas using Inheritance will perform better and we only care about objects that have engines anyway.
The point is, asking the question only at the programming level is starting at the wrong place. We need to recognize always that our starting point should be the analysis model – even if back of a napkin in a small project, and then only proceed to ‘break’ that model deliberately if justified, but recognizing that we are choosing for specific reasons not to model reality.
Great topic.
Timothy:
Thanks for the article! It’s certainly an interesting topic. As an old school C++ then C# programmer, I have a fairly OOP slant.
The one thing I noticed is that your scenario isn’t quite applicable. In your example, you are creating a "Car" class by inheriting the "Engine" class. A car may contain an engine, but it’s not an engine in itself. An engine is mearly a component of a car. In a true scenario, you would compose a "Car" class and inherit that class to make a "Ferrari" class, since a Ferrari is a car.
The answer between inheritance and composition is: Does my class look like the "base" class or is the "base" class simply a component? If your new class _looks_ like the "base" class, then inherit. If the "base" class is simply a component, then compose.
At the end of the day, Inheritance and Composition are just tools in the toolbox that would be used to solve problems.
Thanks for the site. It’s a great read!
Troy:
I went through the same process of appreciation for the differences in these two many years ago. The same arguments interested me as well. Having been originally trained in C++ I had always heard the “is a or has a” semantics. If I reflect back on it I think I was more driven toward inheritance through education because it has more rules associated with it in the language. That makes it harder to learn and it gets more time on the board. I think somehow I drew an incorrect association between time learning and importance of use. Needless to say my early designs suffered and were much more brittle. But much like languages and approaches, I evolved my understanding.
Makes for a great interview question 🙂
You can contribute your thoughts and experiences by sending an Email to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
SharePoint Migration
Written by AvePoint
Microsoft SharePoint Server 2010 is already transformin… (read more)
Featured Script
admin db – table function to get Agent job status
This function is fast and flexible. You can provide either a job name or guid and use the result in a join, as a SARG, or a l… (read more)