Prefer composition over inheritance

Question

Why prefer composition over inheritance   What trade-offs are there for each approach   When should you choose inheritance over composition

User · Answer

These two ways can live together just fine and actually support each other.

Composition is just playing it modular: you create interface similar to the parent class, create new object and delegate calls to it. If these objects need not to know of each other, it's quite safe and easy to use composition. There are so many possibilites here.

However, if the parent class for some reason needs to access functions provided by the "child class" for inexperienced programmer it may look like it's a great place to use inheritance. The parent class can just call it's own abstract "foo()" which is overwritten by the subclass and then it can give the value to the abstract base.

It looks like a nice idea, but in many cases it's better just give the class an object which implements the foo() (or even set the value provided the foo() manually) than to inherit the new class from some base class which requires the function foo() to be specified.

Why?

Because inheritance is a poor way of moving information.

The composition has a real edge here: the relationship can be reversed: the "parent class" or "abstract worker" can aggregate any specific "child" objects implementing certain interface + any child can be set inside any other type of parent, which accepts it's type. And there can be any number of objects, for example MergeSort or QuickSort could sort any list of objects implementing an abstract Compare -interface. Or to put it another way: any group of objects which implement "foo()" and other group of objects which can make use of objects having "foo()" can play together.

I can think of three real reasons for using inheritance:

You have many classes with same interface and you want to save time writing them
You have to use same Base Class for each object
You need to modify the private variables, which can not be public in any case

If these are true, then it is probably necessary to use inheritance.

There is nothing bad in using reason 1, it is very good thing to have a solid interface on your objects. This can be done using composition or with inheritance, no problem - if this interface is simple and does not change. Usually inheritance is quite effective here.

If the reason is number 2 it gets a bit tricky. Do you really only need to use the same base class? In general, just using the same base class is not good enough, but it may be a requirement of your framework, a design consideration which can not be avoided.

However, if you want to use the private variables, the case 3, then you may be in trouble. If you consider global variables unsafe, then you should consider using inheritance to get access to private variables also unsafe. Mind you, global variables are not all THAT bad - databases are essentially big set of global variables. But if you can handle it, then it's quite fine.

User · Answer

Even though Composition is preferred  I would like to highlight pros of Inheritance and cons of Composition   Pros of Inheritance    It establishes a logical  IS A  relation  If Car and Truck are two types of Vehicle   base class   child class IS A base class    i e    Car is a Vehicle  Truck is a Vehicle With inheritance  you can define modify extend a capability   Base class provides no implementation and sub-class has to override complete method  abstract     You can implement a contract Base class provides default implementation and sub-class can change the behaviour    You can re-define contract Sub-class adds extension to base class implementation by calling super methodName   as first statement    You can extend a contract Base class defines structure of the algorithm  and sub-class will override a part of algorithm    You can implement Template method without change in base class skeleton    Cons of Composition    In inheritance  subclass can directly invoke base class method even though it s not implementing base class method because of IS A relation  If you use composition  you have to add methods in container class to expose contained class API   e g  If  Car contains Vehicle and if you have to get price of the Car  which has been defined in Vehicle  your code will be like this  class Vehicle       protected double getPrice                 return price            class Car       Vehicle vehicle       protected double getPrice              return vehicle getPrice

User · Answer

I agree with  Pavel  when he says  there are places for composition and there are places for inheritance   I think inheritance should be used if your answer is an affirmative to any of these questions    Is your class part of a structure that benefits from polymorphism   For example  if you had a Shape class  which declares a method called draw    then we clearly need Circle and Square classes to be subclasses of Shape  so that their client classes would depend on Shape and not on specific subclasses  Does your class need to re-use any high level interactions defined in another class   The template method design pattern would be impossible to implement without inheritance  I believe all extensible frameworks use this pattern    However  if your intention is purely that of code re-use  then composition most likely is a better design choice

User · Answer

I see no one mentioned the diamond problem  which might arise with inheritance    In a glance  if classes B and C inherit A and both override method X  and a fourth class D  inherits from both B and C  and does not override X  which implementation of X D is supposed to use   Wikipedia offers a nice overview of the topic being discussed in this question

User · Answer

With all the undeniable benefits provided by inheritance  here s some of its disadvantages   Disadvantages of Inheritance    You can t change the implementation inherited from super classes at runtime  obviously because inheritance is defined at compile time   Inheritance exposes a subclass to details of its parent class implementation  that s why it s often said that inheritance breaks encapsulation  in a sense that you really need to focus on interfaces only not implementation  so reusing by sub classing is not always preferred   The tight coupling provided by inheritance makes the implementation of a subclass very bound up with the implementation of a super class that any change in the parent implementation will force the sub class to change  Excessive reusing by sub-classing can make the inheritance stack very deep and very confusing too    On the other hand Object composition is defined at runtime through objects acquiring references to other objects  In such a case these objects will never be able to reach each-other s protected data  no encapsulation break  and will be forced to respect each other s interface  And in this case also  implementation dependencies will be a lot less than in case of inheritance

User · Answer

Inheritance is very powerful  but you can t force it  see  the circle-ellipse problem   If you really can t be completely sure of a true  is-a  subtype relationship  then it s best to go with composition

User · Answer

Prefer composition over inheritance as it is more malleable   easy to modify later  but do not use a compose-always approach  With composition  it s easy to change behavior on the fly with Dependency Injection   Setters  Inheritance is more rigid as most languages do not allow you to derive from more than one type  So the goose is more or less cooked once you derive from TypeA   My acid test for the above is      Does TypeB want to expose the complete interface  all public methods no less  of TypeA such that TypeB can be used where TypeA is expected  Indicates Inheritance     e g  A Cessna biplane will expose the complete interface of an airplane  if not more  So that makes it fit to derive from Airplane    Does TypeB want only some part of the behavior exposed by TypeA  Indicates need for Composition       e g  A Bird may need only the fly behavior of an Airplane  In this case  it makes sense to extract it out as an interface   class   both and make it a member of both classes     Update  Just came back to my answer and it seems now that it is incomplete without a specific mention of Barbara Liskov s Liskov Substitution Principle as a test for  Should I be inheriting from this type

User · Answer

Subtyping is appropriate and more powerful where the invariants can be enumerated  else use function composition for extensibility

User · Answer

As many people told  I will first start with the check - whether there exists an  quot is-a quot  relationship  If it exists I usually check the following   Whether the base class can be instantiated  That is  whether the base class can be non-abstract   If it can be non-abstract I usually prefer composition  E g 1  Accountant is an Employee  But I will not use inheritance because a Employee object can be instantiated  E g 2  Book is a SellingItem  A SellingItem cannot be instantiated - it is abstract concept  Hence I will use inheritacne  The SellingItem is an abstract base class  or interface in C   What do you think about this approach  Also  I support  anon answer in Why use inheritance at all   The main reason for using inheritance is not as a form of composition - it is so you can get polymorphic behaviour  If you don t need polymorphism  you probably should not be using inheritance    MatthieuM  says in https   softwareengineering stackexchange com questions 12439 code-smell-inheritance-abuse 12448 comment303759 12448  The issue with inheritance is that it can be used for two orthogonal purposes  interface  for polymorphism  implementation  for code reuse   REFERENCE  Which class design is better  Inheritance vs  Aggregation

User · Answer

While in short words I would agree with  Prefer composition over inheritance   very often for me it sounds like  prefer potatoes over coca-cola   There are places for inheritance and places for composition  You need to understand difference  then this question will disappear  What it really means for me is  if you are going to use inheritance - think again  chances are you need composition    You should prefer potatoes over coca cola when you want to eat  and coca cola over potatoes when you want to drink   Creating a subclass should mean more than just a convenient way to call superclass methods  You should use inheritance when subclass  is-a  super class both structurally and functionally  when it can be used as superclass and you are going to use that  If it is not the case - it is not inheritance  but something else  Composition is when your objects consists of another  or has some relationship to them   So for me it looks like if someone does not know if he needs inheritance or composition  the real problem is that he does not know if he want to drink or to eat  Think about your problem domain more  understand it better

User · Answer

Aside from is a has a considerations  one must also consider the  depth  of inheritance your object has to go through  Anything beyond five or six levels of inheritance deep might cause unexpected casting and boxing unboxing problems  and in those cases it might be wise to compose your object instead

User · Answer

Another  very pragmatic reason  to prefer composition over inheritance has to do with your domain model  and mapping it to a relational database  It s really hard to map inheritance to the SQL model  you end up with all sorts of hacky workarounds  like creating columns that aren t always used  using views  etc   Some ORMLs try to deal with this  but it always gets complicated quickly  Composition can be easily modeled through a foreign-key relationship between two tables  but inheritance is much harder

User · Answer

My general rule of thumb  Before using inheritance  consider if composition makes more sense   Reason  Subclassing usually means more complexity and connectedness  i e  harder to change  maintain  and scale without making mistakes   A much more complete and concrete answer from Tim Boudreau of Sun      Common problems to the use of inheritance as I see it are          Innocent acts can have unexpected results - The classic example of this is calls to overridable methods from the superclass   constructor  before the subclasses instance fields have been   initialized  In a perfect world  nobody would ever do that  This is   not a perfect world    It offers perverse temptations for subclassers to make assumptions about order of method calls and such - such assumptions tend not to   be stable if the superclass may evolve over time  See also my toaster   and coffee pot analogy    Classes get heavier - you don t necessarily know what work your superclass is doing in its constructor  or how much memory it s going   to use  So constructing some innocent would-be lightweight object can   be far more expensive than you think  and this may change over time if   the superclass evolves   It encourages an explosion of subclasses  Classloading costs time  more classes costs memory  This may be a non-issue until you re   dealing with an app on the scale of NetBeans  but there  we had real   issues with  for example  menus being slow because the first display   of a menu triggered massive class loading  We fixed this by moving to   more declarative syntax and other techniques  but that cost time to   fix as well    It makes it harder to change things later - if you ve made a class public  swapping the superclass is going to break subclasses -   it s a choice which  once you ve made the code public  you re married   to  So if you re not altering the real functionality to your   superclass  you get much more freedom to change things later if you   use  rather than extend the thing you need  Take  for example    subclassing JPanel - this is usually wrong  and if the subclass is   public somewhere  you never get a chance to revisit that decision  If   it s accessed as JComponent getThePanel     you can still do it  hint    expose models for the components within as your API     Object hierarchies don t scale  or making them scale later is much harder than planning ahead  - this is the classic  too many layers    problem  I ll go into this below  and how the AskTheOracle pattern can   solve it  though it may offend OOP purists                     My take on what to do  if you do allow for inheritance  which you may   take with a grain of salt is          Expose no fields  ever  except constants   Methods shall be either abstract or final   Call no methods from the superclass constructor                  all of this applies less to small projects than large ones  and less   to private classes than public ones

User · Answer

When can you use composition  You can always use composition  In some cases  inheritance is also possible and may lead to a more powerful and or intuitive API  but composition is always an option  When can you use inheritance  It is often said that if  quot a bar is a foo quot   then the class Bar can inherit the class Foo  Unfortunately  this test alone is not reliable  use the following instead    a bar is a foo  AND bars can do everything that foos can do    The first test ensures that all getters of Foo make sense in Bar    shared properties   while the second test makes sure that all setters of Foo make sense in Bar    shared functionality   Example  Dog Animal A dog is an animal AND dogs can do everything that animals can do  such as breathing  moving  etc    Therefore  the class Dog can inherit the class Animal  Counter-example  Circle Ellipse A circle is an ellipse BUT circles can t do everything that ellipses can do  For example  circles can t stretch  while ellipses can  Therefore  the class Circle cannot inherit the class Ellipse  This is called the Circle-Ellipse problem  which isn t really a problem  but more an indication that  quot a bar is a foo quot  isn t a reliable test by itself  In particular  this example highlights that derived classes should extend the functionality of base classes  never restrict it  Otherwise  the base class couldn t be used polymorphically  Adding the test  quot bars can do everything that foos can do quot  ensures that polymorphic use is possible  and is equivalent to the Liskov Substitution Principle   Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it  When should you use inheritance  Even if you can use inheritance doesn t mean you should  using composition is always an option  Inheritance is a powerful tool allowing implicit code reuse and dynamic dispatch  but it does come with a few disadvantages  which is why composition is often preferred  The trade-offs between inheritance and composition aren t obvious  and in my opinion are best explained in lcn s answer  As a rule of thumb  I tend to choose inheritance over composition when polymorphic use is expected to be very common  in which case the power of dynamic dispatch can lead to a much more readable and elegant API  For example  having a polymorphic class Widget in GUI frameworks  or a polymorphic class Node in XML libraries allows to have an API which is much more readable and intuitive to use than what you would have with a solution purely based on composition

User · Answer

What do you want to force yourself  or another programmer  to adhere to and when do you want to allow yourself  or another programmer  more freedom  It has been argued that inheritance is helpful when you want to force someone into a way of dealing with solving a particular problem so they can t head off in the wrong direction   Is-a and Has-a is a helpful rule of thumb

User · Answer

Inheritance creates a strong relationship between a subclass and super class  subclass must be aware of super class es implementation details  Creating the super class is much harder  when you have to think about how it can be extended  You have to document class invariants carefully  and state what other methods overridable methods use internally    Inheritance is sometimes useful  if the hierarchy really represents a is-a-relationship  It relates to Open-Closed Principle  which states that classes should be closed for modification but open to extension  That way you can have polymorphism  to have a generic method that deals with super type and its methods  but via dynamic dispatch the method of subclass is invoked  This is flexible  and helps to create indirection  which is essential in software  to know less about implementation details    Inheritance is easily overused  though  and creates additional complexity  with hard dependencies between classes  Also understanding what happens during execution of a program gets pretty hard due to layers and dynamic selection of method calls   I would suggest using composing as the default  It is more modular  and gives the benefit of late binding  you can change the component dynamically   Also it s easier to test the things separately  And if you need to use a method from a class  you are not forced to be of certain form  Liskov Substitution Principle

User · Answer

If you understand the difference  it s easier to explain   Procedural Code  An example of this is PHP without the use of classes  particularly before PHP5   All logic is encoded in a set of functions  You may include other files containing helper functions and so on and conduct your business logic by passing data around in functions  This can be very hard to manage as the application grows  PHP5 tries to remedy this by offering more object oriented design   Inheritance  This encourages the use of classes  Inheritance is one of the three tenets of OO design  inheritance  polymorphism  encapsulation    class Person      String Title     String Name     Int Age    class Employee   Person      Int Salary     String Title      This is inheritance at work  The Employee  is a  Person or inherits from Person  All inheritance relationships are  is-a  relationships  Employee also shadows the Title property from Person  meaning Employee Title will return the Title for the Employee not the Person   Composition  Composition is favoured over inheritance  To put it very simply you would have   class Person      String Title     String Name     Int Age      public Person String title  String name  String age          this Title   title        this Name   name        this Age   age           class Employee      Int Salary     private Person person      public Employee Person p  Int salary           this person   p         this Salary   salary          Person johnny   new Person   Mr     John   25   Employee john   new Employee  johnny  50000     Composition is typically  has a  or  uses a  relationship  Here the Employee class has a Person  It does not inherit from Person but instead gets the Person object passed to it  which is why it  has a  Person   Composition over Inheritance  Now say you want to create a Manager type so you end up with   class Manager   Person  Employee              This example will work fine  however  what if Person and Employee both declared Title  Should Manager Title return  Manager of Operations  or  Mr    Under composition this ambiguity is better handled   Class Manager      public string Title     public Manager Person p  Employee e             this Title   e Title           The Manager object is composed as an Employee and a Person  The Title behaviour is taken from employee  This explicit composition removes ambiguity among other things and you ll encounter fewer bugs

User · Answer

This rule is a complete nonsense  Why    The reason is that in every case it is possible to tell whether to use composition or inheritance   This is determined by the answer to a question   IS something A something else  or  HAS  something A something else     You cannot  prefer  to make something to be something else or to have something else  Strict logical rules apply    Also there are no  contrived examples  because in every situation an answer to this question can be given    If you cannot answer this question there is something else wrong   This includes overlapping responsibilities of classess which are usually the result of wrong use of interfaces  less often by rewriting same code in different classess    To avoid this situations I also recommend to use good names for classes   that fully resemble their responsibilities

User · Answer

When you have an is-a relation between two classes  example dog is a canine   you go for inheritance   On the other hand when you have has-a or some adjective relationship between two classes  student has courses  or  teacher studies courses   you chose composition

User · Answer

Suppose an aircraft has only two parts  an engine and wings  Then there are two ways to design an aircraft class     Class Aircraft extends Engine    var wings      Now your aircraft can start with having fixed wings and change them to rotary wings on the fly  It s essentially an engine with wings  But what if I wanted to change the engine on the fly as well     Either the base class Engine exposes a mutator to change its properties  or I redesign Aircraft as      Class Aircraft     var wings    var engine      Now  I can replace my engine on the fly as well

User · Answer

A rule of thumb I have heard is inheritance should be used when its a  is-a  relationship and composition when its a  has-a   Even with that I feel that you should always lean towards composition because it eliminates a lot of complexity

User · Answer

You need to have a look at The Liskov Substitution Principle in Uncle Bob s SOLID principles of class design

User · Answer

To address this question from a different perspective for newer programmers   Inheritance is often taught early when we learn object-oriented programming  so it s seen as an easy solution to a common problem       I have three classes that all need some common functionality  So if I   write a base class and have them all inherit from it  then they will   all have that functionality and I ll only need to maintain it in once   place    It sounds great  but in practice it almost never  ever works  for one of several reasons      We discover that there are some other functions that we want our classes to have  If the way that we add functionality to classes is through inheritance  we have to decide - do we add it to the existing base class  even though not every class that inherits from it needs that functionality  Do we create another base class  But what about classes that already inherit from the other base class  We discover that for just one of the classes that inherits from our base class we want the base class to behave a little differently  So now we go back and tinker with our base class  maybe adding some virtual methods  or even worse  some code that says   If I m inherited type A  do this  but if I m inherited type B  do that   That s bad for lots of reasons  One is that every time we change the base class  we re effectively changing every inherited class  So we re really changing class A  B  C  and D because we need a slightly different behavior in class A  As careful as we think we are  we might break one of those classes for reasons that have nothing to do with those classes  We might know why we decided to make all of these classes inherit from each other  but it might not  probably won t  make sense to someone else who has to maintain our code  We might force them into a difficult choice - do I do something really ugly and messy to make the change I need  see the previous bullet point  or do I just rewrite a bunch of this    In the end  we tie our code in some difficult knots and get no benefit whatsoever from it except that we get to say   Cool  I learned about inheritance and now I used it   That s not meant to be condescending because we ve all done it  But we all did it because no one told us not to    As soon as someone explained  favor composition over inheritance  to me  I thought back over every time I tried to share functionality between classes using inheritance and realized that most of the time it didn t really work well   The antidote is the Single Responsibility Principle  Think of it as a constraint  My class must do one thing  I must be able to give my class a name that somehow describes that one thing it does   There are exceptions to everything  but absolute rules are sometimes better when we re learning   It follows that I cannot write a base class called ObjectBaseThatContainsVariousFunctionsNeededByDifferentClasses  Whatever distinct functionality I need must be in its own class  and then other classes that need that functionality can depend on that class  not inherit from it   At the risk of oversimplifying  that s composition - composing multiple classes to work together  And once we form that habit we find that it s much more flexible  maintainable  and testable than using inheritance

User · Answer

Think of containment as a has a relationship  A car  quot has an quot  engine  a person  quot has a quot  name  etc  Think of inheritance as an is a relationship  A car  quot is a quot  vehicle  a person  quot is a quot  mammal  etc  I take no credit for this approach  I took it straight from the Second Edition of Code Complete by Steve McConnell  Section 6 3

User · Answer

Inheritance is a very powerfull machanism for code reuse  But needs to be used properly  I would say that inheritance is used correctly if the subclass is also a subtype of the parent class  As mentioned above  the Liskov Substitution Principle is the key point here    Subclass is not the same as subtype  You might create subclasses that are not subtypes  and this is when you should use composition   To understand what a subtype is  lets start giving an explanation of what a type is   When we say that the number 5 is of type integer  we are stating that 5 belongs to a set of possible values  as an example  see the possible values for the Java primitive types   We are also stating that there is a valid set of methods I can perform on the value like addition and subtraction  And finally we are stating that there are a set of properties that are always satisfied  for example  if I add the values 3 and 5  I will get 8 as a result   To give another example  think about the abstract data types  Set of integers and List of integers  the values they can hold are restricted to integers  They both support a set of methods  like add newValue  and size    And they both have different properties  class invariant   Sets does not allow duplicates while List does allow duplicates  of course there are other properties that they both satisfy    Subtype is also a type  which has a relation to another type  called parent type  or supertype   The subtype must satisfy the features  values  methods and properties  of the parent type  The relation means that in any context where the supertype is expected  it can be substitutable by a subtype  without affecting the behaviour of the execution  Let   s go to see some code to exemplify what I   m saying  Suppose I write a List of integers  in some sort of pseudo language    class List     data   new Array       Integer size         return data length         add Integer anInteger        data data length    anInteger          Then  I write the Set of integers as a subclass of the List of integers   class Set  inheriting from  List     add Integer anInteger         if  data notContains anInteger            super add anInteger                  Our Set of integers class is a subclass of List of Integers  but is not a subtype  due to it is not satisfying all the features of the List class  The values  and the signature of the methods are satisfied but the properties are not  The behaviour of the add Integer  method has been clearly changed  not preserving the properties of the parent type  Think from the point of view of the client of your classes  They might receive a Set of integers where a List of integers is expected  The client might want to add a value and get that value added to the List even if that value already exist in the List  But her wont get that behaviour if the value exists  A big suprise for her   This is a classic example of an improper use of inheritance  Use composition in this case    a fragment from  use inheritance properly

User · Answer

Composition v s Inheritance is a wide subject  There is no real answer for what is better as I think it all depends on the design of the system   Generally type of relationship between object provide better information to choose one of them   If relation type is   IS-A  relation then Inheritance is better approach  otherwise relation type is   HAS-A  relation then composition will better approach   Its totally depend on entity relationship

User · Answer

Inheritance is pretty enticing especially coming from procedural-land and it often looks deceptively elegant  I mean all I need to do is add this one bit of functionality to some other class  right  Well  one of the problems is that inheritance is probably the worst form of coupling you can have  Your base class breaks encapsulation by exposing implementation details to subclasses in the form of protected members  This makes your system rigid and fragile  The more tragic flaw however is the new subclass brings with it all the baggage and opinion of the inheritance chain   The article  Inheritance is Evil  The Epic Fail of the DataAnnotationsModelBinder  walks through an example of this in C   It shows the use of inheritance when composition should have been used and how it could be refactored

User · Answer

Didn t find a satisfactory answer here  so I wrote a new one   To understand why  prefer composition over inheritance   we need first get back the assumption omitted in this shortened idiom   There are two benefits of inheritance  subtyping and subclassing   Subtyping means conforming to a type  interface  signature  i e  a set of APIs  and one can override part of the signature to achieve subtyping polymorphism  Subclassing means implicit reuse of method implementations    With the two benefits comes two different purposes for doing inheritance  subtyping oriented and code reuse oriented   If code reuse is the sole purpose  subclassing may give one more than what he needs  i e  some public methods of the parent class don t make much sense for the child class  In this case  instead of favoring composition over inheritance  composition is demanded  This is also where the  is-a  vs   has-a  notion comes from   So only when subtyping is purposed  i e  to use the new class later in a polymorphic manner  do we face the problem of choosing inheritance or composition  This is the assumption that gets omitted in the shortened idiom under discussion   To subtype is to conform to a type signature  this means composition has always to expose no less amount of APIs of the type  Now the trade offs kick in    Inheritance provides straightforward code reuse if not overridden  while composition has to re-code every API  even if it s just a simple job of delegation  Inheritance provides straightforward open recursion via the internal polymorphic site this  i e  invoking overriding method  or even type  in another member function  either public or private  though discouraged   Open recursion can be simulated via composition  but it requires extra effort and may not always viable     This answer to a duplicated question talks something similar  Inheritance exposes protected members  This breaks encapsulation of the parent class  and if used by subclass  another dependency between the child and its parent is introduced  Composition has the befit of inversion of control  and its dependency can be injected dynamically  as is shown in decorator pattern and proxy pattern  Composition has the benefit of combinator-oriented programming  i e  working in a way like the composite pattern  Composition immediately follows programming to an interface  Composition has the benefit of easy multiple inheritance    With the above trade offs in mind  we hence prefer composition over inheritance  Yet for tightly related classes  i e  when implicit code reuse really make benefits  or the magic power of open recursion is desired  inheritance shall be the choice

User · Answer

A simple way to make sense of this would be that inheritance should be used when you need an object of your class to have the same interface as its parent class  so that it can thereby be treated as an object of the parent class  upcasting   Moreover  function calls on a derived class object would remain the same everywhere in code  but the specific method to call would be determined at runtime  i e  the low-level implementation differs  the high-level interface remains the same    Composition should be used when you do not need the new class to have the same interface  i e  you wish to conceal certain aspects of the class  implementation which the user of that class need not know about  So composition is more in the way of supporting encapsulation  i e  concealing the implementation  while inheritance is meant to support abstraction  i e  providing a simplified representation of something  in this case the same interface for a range of types with different internals

User · Answer

Personally I learned to always prefer composition over inheritance  There is no programmatic problem you can solve with inheritance which you cannot solve with composition  though you may have to use Interfaces Java  or Protocols Obj-C  in some cases  Since C   doesn t know any such thing  you ll have to use abstract base classes  which means you cannot get entirely rid of inheritance in C     Composition is often more logical  it provides better abstraction  better encapsulation  better code reuse  especially in very large projects  and is less likely to break anything at a distance just because you made an isolated change anywhere in your code  It also makes it easier to uphold the  Single Responsibility Principle   which is often summarized as  There should never be more than one reason for a class to change    and it means that every class exists for a specific purpose and it should only have methods that are directly related to its purpose  Also having a very shallow inheritance tree makes it much easier to keep the overview even when your project starts to get really large  Many people think that inheritance represents our real world pretty well  but that isn t the truth  The real world uses much more composition than inheritance  Pretty much every real world object you can hold in your hand has been composed out of other  smaller real world objects   There are downsides of composition  though  If you skip inheritance altogether and only focus on composition  you will notice that you often have to write a couple of extra code lines that weren t necessary if you had used inheritance  You are also sometimes forced to repeat yourself and this violates the DRY Principle  DRY   Don t Repeat Yourself   Also composition often requires delegation  and a method is just calling another method of another object with no other code surrounding this call  Such  double method calls   which may easily extend to triple or quadruple method calls and even farther than that  have much worse performance than inheritance  where you simply inherit a method of your parent  Calling an inherited method may be equally fast as calling a non-inherited one  or it may be slightly slower  but is usually still faster than two consecutive method calls   You may have noticed that most OO languages don t allow multiple inheritance  While there are a couple of cases where multiple inheritance can really buy you something  but those are rather exceptions than the rule  Whenever you run into a situation where you think  multiple inheritance would be a really cool feature to solve this problem   you are usually at a point where you should re-think inheritance altogether  since even it may require a couple of extra code lines  a solution based on composition will usually turn out to be much more elegant  flexible and future proof   Inheritance is really a cool feature  but I m afraid it has been overused the last couple of years  People treated inheritance as the one hammer that can nail it all  regardless if it was actually a nail  a screw  or maybe a something completely different

User · Answer

In Java or C   an object cannot change its type once it has been instantiated   So  if your object need to appear as a different object or behave differently depending on an object state or conditions  then use Composition  Refer to State and Strategy Design Patterns   If the object need to be of the same type  then use Inheritance or implement interfaces

User · Answer

When you want to  copy  Expose the base class  API  you use inheritance  When you only want to  copy  functionality  use delegation   One example of this  You want to create a Stack out of a List  Stack only has pop  push and peek  You shouldn t use inheritance given that you don t want push back  push front  removeAt  et al -kind of functionality in a Stack

[language-agnostic] Prefer composition over inheritance?

Examples related to language-agnostic

Examples related to oop

Examples related to inheritance

Examples related to composition

Examples related to aggregation