Introduction
From the early days of object oriented programming, there is a practice of using (rather abusing) inheritance. Many developers find comfort in defining an abstract class with common code implemented as virtual in base class. The major reason behind having this notion is to use override feature to modify behavior if required and to support code reusability. But doing so makes the code fragile over a period as base class starts to have more and more virtual methods which may not be required by all its derived classes.
In the below article, we will first see what it means by having composition in class designing. We will see how composition avoids the chronic 'object pollution issue', a byproduct of incorrect inheritance. This article explains the use of Composition in WPF applications, but it can very well be used in others as well.
Problem
Let's try to create a system having different types of users (Manager, Coder, and Leader). All users should have printer related operation access.System should support features as: Print, Fax, Scan, Email.
Mapping between Users and printer functionalities should be as follows:
Manager: Print, Fax, Scan, Email Leader: Print, Scan Coder: Print
Composition Solution
Let's try to solve this problem following composition. From the above problem definition, we can imagine some software entities and interface that could be used in implementation.
- Interfaces:
IPrinter, IEmployee - Classes:
SuperPrinter, AvergePrinter, BasicPrinter, Manager, Coder, Leader
All the above mentioned inferences are plain representation of actors and actions defined in functional specifications. Nowhere in functional specification will you find a reference of printer as a plug-in for user operations. But if you carefully go through the spec, you can imagine interface IPrinterEnabled which would expose Printer interface as property allowing user to plug concrete printer object at construction time.
This kind of plug and play allows the system to stay flexible for future changes as user may reorder relationship between user and printer (e.g. allowing Leader to use SuperPrinter).
Please refer to the below class diagram explaining the same:
You can also refer to the attached WPF example depicting implementation of it.
Inheritance Solution
I want to explain how we could have gone with the inheritance approach to solve the above problem. Note that the application will behave exactly the same for end users, oblivious to rigidity that system develops for change. I don't want to get into descriptions of implementation, you can check the class diagram and the attached code for understanding.
Referring to the above diagram and code, you will find that concrete user classes have been polluted by additional knowledge of printer features. Though they may internally use printer object to divert calls to appropriate execution, it makes compulsion on the developer to either come with a base class to have these printer signatures implemented and make them virtual so that can be overriden by derived classes or implement interface on all concrete classes.
Developers generally go for base class approach thinking that if IPrinterCommand interface changes over time, they would just be required to create the appropriate virtual method in base class. This is an insane mistake smelling the rottenness of design, as it requires modifying existing (& working) base class source code and updating all derived classes depend on the specific changes.
Conclusion
As you have seen, both the approaches have a few common classes, but there is a subtle variation in the way user classes use printer functionality. In the inheritance approach, printer functionality is inherited into derived user object showing tight coupling between users and print functionality. Whereas in Composition, user classes are made printer enabled by allowing them to be inherited from IPrinterEnabled interface, giving developer advantage of assigning printer functionality as plug-in to user objects. And we can very well say that user objects in composition approach are not polluted by printing functionality.
Note: I have used the above example as a random scenario. This may not be a practical scenario. Given the fact that all developers are used to hearing crazy requirements, this example won't drive you crazy.
