Composition vs. Inheritance

[hemanbansal]

Hi Guys,

Can anyone tell What is composition? in detail along with its differences with inheritance in general.

[JosAH]

Hi Guys,

Can anyone tell What is composition? in detail along with its differences with inheritance in general.

There are two major relationships between classes (objects thereof). The
relationships are "is-a" and "has-a". The first relation can be implemented using
inheritance, while the second relationship is normally implemented using
composition. For the first relationship a Liskov Substitution Principle can
decide whether or not inheritance is the way to go. For the second relationship
the front end class (the composite) acts as a delegator to its member objects.

kind regards,

Jos

[weaknessforcats]

Composition is the HAS-A form of class relationships. This mean you will have an object inside your class:

class Car
{
    private:
       Vechicle v;
};
 

You will now need a Car method to access the Vehicle object.

Inheritance is the IS-A form of class realtionships. As in a Car IS-A Vechicle. Here the Vehicle methods are inherited and you are not required to have a Car method to call a Vechicle method:

class Car : public Vehicle
{
 
};
 

So, composition is exactly the same as:

class Car : private Vehicle
{
 
};
 

because, again, the Vechicle is private so you need a Car method to call a Vechicle method. Private inheritantace is often called implementation inheritance since you get the Vehicle as a base class but the Vehicle methods are not available to Car users, that is, the Vechicle implementation has been hidden by the Car.

[AdrianH]

There are two major relationships between classes (objects thereof). The
relationships are "is-a" and "has-a". The first relation can be implemented using
inheritance, while the second relationship is normally implemented using
composition. For the first relationship a Liskov Substitution Principle can
decide whether or not inheritance is the way to go. For the second relationship
the front end class (the composite) acts as a delegator to its member objects.

kind regards,

Jos

It should be noted that although "has-a" can be implemented using compositions, it can also be implemented through aggregation.


Adrian

[AdrianH]

Composition is the HAS-A form of class relationships. This mean you will have an object inside your class:

class Car
{
    private:
       Vechicle v;
};
 

You will now need a Car method to access the Vehicle object.

Inheritance is the IS-A form of class realtionships. As in a Car IS-A Vechicle. Here the Vehicle methods are inherited and you are not required to have a Car method to call a Vechicle method:

class Car : public Vehicle
{
 
};
 

So, composition is exactly the same as:

class Car : private Vehicle
{
 
};
 

because, again, the Vechicle is private so you need a Car method to call a Vechicle method. Private inheritantace is often called implementation inheritance since you get the Vehicle as a base class but the Vehicle methods are not available to Car users, that is, the Vechicle implementation has been hidden by the Car.

Yeah, I hate it when people use implementation inheritance, I find that it is a bastardisation of inheritance. But of course, I also disagree with multiple inheritance as well as it complicates things and can make code unmanageable.

Both of these types (implementation and multiple inheritance) do have some uses, but I find interface and single inheritance are far cleaner.

But going back to the example that weakness gave, I think that replacing Car with an actual specialisation type, say Honda or Honda Civic, would be better, because Car and Vehicle are both fairly generic in description, and though you can say that a Car is a specialisation of Vehicle, it doesn’t give a very pronounced separation between the two.

Just my 2 cents worth.


Adrian

[weaknessforcats]

Yeah, I hate it when people use implementation inheritance, I find that it is a bastardisation of inheritance. But of course, I also disagree with multiple inheritance as well as it complicates things and can make code unmanageable.

You need to do this when your interface is not to contain methods outside the design spec. Private inheritance is identical to a private data member.

Multiple inheritance is harder to justify. However, multiple base classes is the way to provide multiple interfaces to your classes. Evem C# and Java have a form of this with the "implements" keyword.

But going back to the example that weakness gave, I think that replacing Car with an actual specialisation type, say Honda or Honda Civic, would be better,

Possibly. Certainly this is a design choice that could be made. There are no right answers here. A single solution can have many designs.

[AdrianH]

You need to do this when your interface is not to contain methods outside the design spec. Private inheritance is identical to a private data member.

No, private inheritance is not identical. With private inheritance, you may call a public member function from the privatly inherited class as if it were part of the class doing the inheriting. With a private data member, you need to invoke the member function with the correct object.

Multiple inheritance is harder to justify. However, multiple base classes is the way to provide multiple interfaces to your classes. Evem C# and Java have a form of this with the "implements" keyword.

Hence my comment on interface inheritance.

Possibly. Certainly this is a design choice that could be made. There are no right answers here. A single solution can have many designs.

Of course.


Adrian