Click here to Skip to main content
15,124,449 members
Articles / Web Development / ASP.NET
Posted 1 May 2011


12 bookmarked

Object Composition Over Inheritance

Rate me:
Please Sign up or sign in to vote.
3.78/5 (8 votes)
1 May 2011CPOL3 min read
Why to prefer object composition over inheritance


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.


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.


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.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Software Developer
Australia Australia
No Biography provided

Comments and Discussions

QuestionCommand Pattern?? Pin
nportelli21-Oct-13 6:41
Membernportelli21-Oct-13 6:41 
GeneralDon't Understand Pin
Joe_Developer13-May-11 3:28
MemberJoe_Developer13-May-11 3:28 
GeneralRe: Don't Understand Pin
User-Rock13-May-11 3:42
MemberUser-Rock13-May-11 3:42 
GeneralRe: Don't Understand Pin
Joe_Developer13-May-11 3:47
MemberJoe_Developer13-May-11 3:47 
GeneralRe: Don't Understand Pin
User-Rock13-May-11 3:54
MemberUser-Rock13-May-11 3:54 
GeneralHidden gem Pin
Seth Morris10-May-11 8:48
MemberSeth Morris10-May-11 8:48 
GeneralRe: Hidden gem Pin
User-Rock13-May-11 3:46
MemberUser-Rock13-May-11 3:46 
GeneralMy vote of 3 Pin
Justin Helsley9-May-11 12:45
MemberJustin Helsley9-May-11 12:45 
GeneralMy vote of 3 Pin
Toli Cuturicu2-May-11 9:36
MemberToli Cuturicu2-May-11 9:36 
Almost 4, but not quite so.
I'll be back to check it after some revisions.
GeneralMy vote of 3 Pin
CoolDadTx2-May-11 5:01
MemberCoolDadTx2-May-11 5:01 
GeneralOOD Concepts Pin
CoolDadTx2-May-11 5:00
MemberCoolDadTx2-May-11 5:00 
GeneralRe: OOD Concepts Pin
User-Rock2-May-11 5:25
MemberUser-Rock2-May-11 5:25 
GeneralMy vote of 4 Pin
BigJim612-May-11 1:55
MemberBigJim612-May-11 1:55 
GeneralRe: My vote of 4 Pin
User-Rock2-May-11 5:03
MemberUser-Rock2-May-11 5:03 
GeneralBoth samples are suboptimal Pin
Robert Rohde2-May-11 0:13
MemberRobert Rohde2-May-11 0:13 
GeneralToo simplistic Pin
gpgemini1-May-11 23:42
Membergpgemini1-May-11 23:42 
GeneralRe: Too simplistic Pin
User-Rock2-May-11 4:48
MemberUser-Rock2-May-11 4:48 
GeneralRe: Too simplistic Pin
gpgemini2-May-11 4:55
Membergpgemini2-May-11 4:55 
GeneralCan you fix the images please ? Pin
Remi BOURGAREL1-May-11 23:32
MemberRemi BOURGAREL1-May-11 23:32 
GeneralRe: Can you fix the images please ? Pin
User-Rock2-May-11 4:42
MemberUser-Rock2-May-11 4:42 
GeneralRe: Can you fix the images please ? Pin
Remi BOURGAREL2-May-11 5:20
MemberRemi BOURGAREL2-May-11 5:20 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.