Composition vs Inheritance choice - the true story.

As an inexperienced developer keeps diving into new ideas of software design, a time will come when the contradiction between composition and inheritance became the question.

Composition over Inheritance is a popular principle in Object Oriented design. Below we will try to make things clear about the choice from between those two along the development process.

Before we even move forward we assume that the terms of a basic software engineering terms such as aggregation, association and the UML basics are clear to the reader [see our article].

In object oriented design it is a fundamental activity to establish class relations. The functionality two discussed methods - composition and inheritance - are

Let us first consider the nature of both terms.

One of the fundamental activities of an object-oriented design is establishing relationships between classes. Two fundamental ways to relate classes are inheritance and composition. It is worth mentioning that you can get at the functionality of inheritance when you use composition. This article will compare these two approaches to relating classes and will provide guidelines on their use.

Composition

As the name itself tell the composition is about  building something out of smaller parts. The key to understand composition in a right way is to understand aggregation and association. In this article we will focus around composition as a instance variables referencing to other objects.

public class A{
    private B b = new B();
}

Inheritance

Along this article inheritance would mean a single inheritance through class extension.

public class A{...}
public class B extends A{...}

Benefits of inheritance:

• advantage of dynamic binding.
  Dynamic binding is a JVM mechanism that is responsible for choosing which method implementation will be invoked at runtime based on the class of the object.
• Polymorphism -
  In general means to use a variable of a superclass type to hold a reference to an object whose class is the superclass or any of its subclasses

Both of the above can help make code easier to change. This is nice as long as you want to add a new type of a subclass.

However, this is not the case when the change involves class structure.

Composition vs Inheritance

The superclass in inheritance is often referred to as a fragile. It is because one change in superclass structure will force changes in many subclasses. The fragile part of superclass is its interface. In case of a well-designed superclass with a clean separation of interface and implementation in the object-oriented style, any changes to the superclass's implementation shouldn't cause problems at all. However, if we try to change the interface even the best design will not help breaking subclasses code.

Example:

public class A {
    //interface method:
    public int m1(){...} // change int to Integer return value 
}

The change of the type from int to Integer can cause errors in subclasses that invokes that method on any reference of type A. What is more even if subclasses override this method this would also cause braking code. The only way to solve this problem is to move along the entire A class inheritance hierarchy and modify every interface part that need to conform the new look of the superclass.

What is more, if you have code directly using subclass of a A class that the code will also suffer from superclass interface modification. That is the reason to state the inheritance provide “weak encapsulation”.
Inheritance allows subclass to reuse code from superclass if it is not overriding it. However, the subclass of A only “weakly encapsulates” the A class code it is reusing, as the changes to A’s interface can break code that directly uses such subclass.

In such situation let us move to alternate solution provided by composition. In terms of code reuse, composition turns out to be more code changing friendly.

• Inherited code reuse
  

Let  us consider some code using inheritance:

class A {
     // Return int value  resulted from the method activity.
    public int method1() {
      System.out.println("Method 1. from class A");
      return 1;
    }
}

class B extends A {}

class MainClass {

  public static void main(String[] args) {
    B b = new B();
    int v = B.method1();
  }
}

The application would result in printout of: “Method 1. from class A”, because B inherits (therefore, reuses) A’s implementation of method1(). However, if in the future one would want to change the construction of method1() in A class, then the entire application would broke. This would happen even if the use of A class is indirect through the B class.

• Composed code reuse

The same example can be handled with composition.

class A {
    // Return int value  resulted from the method activity.
   public int method1() {
      System.out.println("Method 1. from class A.");
      return 1;
   }
}


class B {

    private A aVar = new A();

   public int method1() {
      return aVar.method1();
   }
}

class MainClass2 {

public static void main(String[] args) {

    B b = new B();
    int v = b.method1();
  }
}

In this approach the B class due to composition construct, becomes front-end class while the superclass A plays a role of back-end class. In contrast to inherited version we have an overridden implementation or pure code reuse from superclass in other case. With composition we have an explicit method call to the method of the back-end superclass. This is sometimes called forwarding or delegation.

What is more composition brings stronger encapsulation than inheritance. It is because each time we change a method from superclass the code relying on the subclass is not broken. So e.g. changing the method1() return value from A class would not force change in the interface of class B and thus no problems caused in the main application using the B class only. The problem might arise in class B method1() but not in the main app.

This way the main project is not affected. 

Compare & Contrast: composition & inheritance

1. As shown in previous section it is much less complicated to propagate changes from back-end class down the hierarchy with composition that it is superclass down the inheritance hierarchy.
   In composition, change to the back-end class interface would force possible changes in front-end class implementation but not its interface. Therefore the change does not have to propagate. The code depending on front-end class interface still can work if it interface does not change with the back-end class interface change.
   In case of inheritance any change to superclass’s interface would not only force changes down the inheritance hierarchy of classes but will cause problems with the code using those classes.
2. The problem however arises also when we try to modify the second classes: front-class in case of composition or subclass in case of inheritance.
   In inheritance it is impossible to change the subclass’s interface in a way that is not confirming the compatibility with the superclass interface. E.g. it is not possible to add to the subclass a new method with the same signature but with different return type as a method inherited from superclass.Composition allows the change of interface of front-end class without affecting back-end classes.
3. The aspect of object creation. Composition is capable of lazy creation of back-end objects until they are really needed and what is more, the back-end objects can be changed during the lifetime of the front-object.
   Inheritance on the other hand creates superclass part as soon as subclass is being created. It is part of a subclass object to the end of its lifetime.
4. Polymorphism of inheritance comes with ease of creation of new subclasses. A superclass interface code will work with any new subclass created.Composition without use of interfaces does not bring such feature. However adding interface to composition can overcome this limitation. [see article]
5. In most cases the performance of explicit method invocation forwarding (delegation) from composition is less efficient comparing to single invocation of an inherited superclass method implementation. This is however mostly JVM related.

When Compose when Inherit?

The A,B,C rules of thumb.

   

1. Inherit only when is-a relationship exist. Use inheritance only when the  subclass IS-A superclass:
   e.g. Car is-a Vehicle, Horse is-a Mammal etc.
   What is more this relation must be true along the lifetime of an application using speciffic domain model
   e.g. Employee is-a Person up to a point when an Employee becomes unemployed or a Supervisor. So Employee is not a Person but a role a person plays during the lifetime of application. In this case we should consider composition
2. The code reuse can not determine the use of inheritance. Only the is-a relationship is valid determinant. Otherwise use composition.
3. The polymorphism can not determine the use of inheritance. Without IS-A relationship it is enough to use composition with interfaces instead of inheritance. [see article]
   
   

so[L]id 

Let us mention here one of the most important principles in object-oriented design :

SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion). 

Actually we will focus here only on the L (LSP) part of this acronym.

objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Typical violation of this principle is with a specific class that inherits from more general class. E.g. Square inherits from Rectangle. Let us assume we would have a method called calculateField() resulting in field value as a product. Now if we would consider a Square as a Rectangle then it's sides length still must stay the same.
Now changing the side lengthto the Square i.e. :

rectangle.setWidth(10);
rectangle.setHeight(20);

would cause some unexpected behavior because there should be a mechanism assuring that both sides are even in case of Square and in Rectangle there is none. 

What is more the result of the field would be 100 for square instead expected 200 for rectangle. Therefore this voilates the Liskov substitution as it is not working as expected.

From Asotiation to Composition & More.

Association, Aggregation, Composition, Inheritance - what are those?

(OOP, UML)

Either association and aggregation  topic terms are both concepts of software design. They are considered in terms of relation between two classifiers, such as classes (but also use cases), that describe the relation reasons and rules  that governs it.
In this article we assume readers basic knowledge of UML class diagrams.

A relationship is a general term covering the specific types of logical connections found on class and object diagrams in UML.

Below we will try to focus on gathering information about a relationship between classes of objects:

Inheritance > Composition > Aggregation > Association > Link

Link

The most general relationship is Link. It simply only gives a notion of a relation not describing its particular properties. A link is a relationship between objects or instances of the classifiers. In general Link is an instance of an association, while an association is a relationship between two classifiers.

  

Association: uses a

Ex:a Class Man uses a Class Pen

It is the weakest of all relations. An association represents a structural relationship that connects two classifiers. Like attributes, associations record the properties of classifiers.

For example, in relationships between classes, you can use associations to show the design decisions that you made about classes in your application that contain data, and to show which of those classes need to share data. You can use an association's navigability feature, to show how an object of one class gains access to an object of another class or, in a reflexive association, to an object of the same class.    The name of an association describes the nature of the relationship between two classifiers and should be a verb or phrase. In the diagram editor, an association appears as a solid line between two classifiers.

In General:

• temporal relation between objects
• objects associated are independent (deleting one does not mean delete second)
• associated objects contain reference to the other object
• In Java equal to field

Example:

Passenger knows about his ticket reservations and reservation knows about who is its owner. In case reservation does not have reference to passenger when the association is unidirectional type (with an arrow in UML). With bidirectional association there are no arrows and both objects have references to each other

• In Java

The association relationship is a way of describing that a class knows about and holds a reference to another class. This can be described as a "has-a" relationship because the typical implementation in Java is through the use of an instance field. The relationship can be bi-directional with each class holding a reference to the other. Below there is a bi-directional association implemented many-to-one in Java using fields:

public class Department {

private Set staff = new HashSet();
...
}

public class Employee {

private Department department;
...
}

To make it uni-directional, one of the classes would not have its relation field.

What is the problem with a bi-directional association?

Unlike a relation in a RDBMS, a bi-directional association is stored on two ends. Lets illustrate it with example. We want to add a new employee to a department:

Department sales     = DepartmentsStore.getDepartment(...);
Department it        = DepartmentsStore.getDepartment(...);

Employee john = Employees.getEmployee(“john_id”);

john.getDepartment(); //  Lets say JOHN works in “IT” dept.

john.setDepartment(sales); //!? 

This would not work. We would still had to add “john” to “sales” and remove him from “it”:

sales.getStaff().add(john);
it.getStaff().remove(john);

So we have to take care of all this maintenance. Otherwise the application would collapse. And you can imagine in how many places this would have to be repeated in enterprise application.

Lets make it more OOP in terms of behaviour and responsibilities. We would have to consider business logic. Thats why we assume that the hire/fire is responsibility of Department.

public void hire(Employee employee)throws HumanResourceException {
staff.add(employee);
}

public void fire(Employee employee) throws HumanResourceException {

if (!staff.contains(employee)) throw new HumanResourceException("Employee does not work at this department");

staff.remove(employee);

}

But this is only the Department part not the Employee state needs to be modified:

void _changeDepartment(Departmentdepartment) {
    assert this.department == null;

    this.department = department;
}

void _removeFromItsDepartment() {
    assert this.department != null;
    this.department = null;

}

But still those methods should be used only by Department and there is no way to limit the scope of a method to one other class. You can only put it to the same package and follow convention of underscore meaning “used internally”.

This is still ugly and do it at home or work by yourself.

Aggregation: has a

Ex:a Class Man has a Class Car ( Car is still there when Man die )

Aggregation (white diamond) has no semantics beyond that of a regular association. It is, as Jim Rumbaugh puts it, a modeling placebo. People can, and do, use it - but there are no standard meanings for it. So if you see it, you should inquire as to what the author means by it. I would advise not using it yourself without some form of explanation.       

- Martin Fowler

This relationship is described as a “has-a” or “whole/part” relation between two classes. It is more strict relation than association. One of the classes - so called aggregate class - contains reference to the second class and is therefore said to have ownership of that second class. The class that is being referenced from within aggregate class is considered to be part-of the aggregate class. Aggregation is a stronger case of association as a directional association between objects.
You can say that you have aggregation between two objects when an object “has-a” another object. The additional information about relation’s direction is determined by deciding which object contains the other object.

In General:

• Stronger than association
• there is an owner and owned connected with their time of existence
• It is part-to-whole type of relation i.e. a part might belong to many unities therefore unity do not govern time of “part” existence
• aggregation means enclosing

Example:

• The university division does NOT create nor delete instance of professor it only contains it.
• Book register at library and particular book card. The register encloses book cards.
  
  
  
  

Composition: contains/owns a (Total composition) HAS-A

Ex:a Class Man owns a Class Heart ( When Man die, Heart die )

Composition (black diamond) does carry semantics. The most particular is that an object can only be the part of one composition relationship. So even if both windows and panels can hold menu-bars, any instance of menu-bar must be only held by one whole. This isn't a constraint that you can easily express with the regular multiplicity markers.   

- Martin Fowler

The strongest from the relationships. Composition is a special case of aggregation. A restricted aggregation is called composition. Therefore, composition is when a an object contains the other object and the contained object cannot exist without the existence of container object. In ther words: composition ensure that the containing object is responsible for the lifetime of the object it holds. If Object BAR is contained within Object FOO, then Object FOO is responsible for the creation and destruction of Object BAR. Unlike aggregation, Object BAR cannot exist without Object FOO.

In General:

• Just like aggregation relationship of part-whole
• The Whole object is the only owner, creator and administrator of the Part object.
• Part and Whole cannot exist without each other ie. their time of existence is connected
• deleting the Whole object removes all its Part objects
• Referred as “has-a”

Example:

• Encyklopedia has many toms.
• University has a Department
  

REMEMBER:

Both Composition and Aggregation are Associations.
Composition IS-A strong Association.
Aggregation IS-A weak Association.

Inheritance/Generalization: IS-A

Ex:a Class Man is a Class Human ( Man is a Human )

As the name inheritance suggests an object is able to inherit characteristics from another object. In more concrete terms, an object is able to pass on its state and behaviors to its children. For inheritance to work the objects need to have characteristics in common with each other. Inheritance can be defined as the process where one object acquires the properties of another. With the use of inheritance the information is made manageable in a hierarchical order. When we talk about inheritance, the most commonly used keyword would be extends and implements. These words would determine whether one object IS-A type of another. By using these keywords we can make one object acquire the properties of another object.

• Java

There is a quite complex explanation of how to consider inheritance in java at Java1 and Java2

General Example 1:

And the code:

public abstract class Item {

        int positionInList;
        String fullName;
}

public class MenuItem extends Item{

        Currency price;
        String description;

void changePrice (Currency newPrice){
             this.price = newPrice;
      }
}


/* AGGREGATION
* In Menu we can change MenuItem price, but the mItem is not only internal consern of Menu.
* It can be swapped, or even completely removed.
*/

public final class Menu {

      private List<MenuItem> mItem;


void addMenuItem(MenuItem mi){
            mItem.add(mi);
}

void changePrice(Currency newPrice, int position){

    if (mItem.get(position) != null){
      mItem..get(position).changePrice(newPrice);
    }
 }
}

public class Order {

private final List<OrderItem> oItems;

Order(List<OrderItem> items){
   this.oItems = new ArrayList<OrderItem>();
   this.oItems.addAll(items);
}

void modifyItem(String wish, int position){
    oIitems.get(pos).addNote(wish);
  }
}

public final class OrderItem extends Item{

String guestNotes;
List<int> positionInMenu;

private final addNote(String wish){
   this.guestNotes = wish;
}
}

General Example 2:

And the code:

public class University {

private List<Department> departments;

public void destroy(){
//it's composition, when i destroy a university I also destroy the departments. they cant live outside my university instance
    if(departments!=null)
    for(Department d : departments)
       d.destroy();
    departments.clean();
    departments = null;
  }
}

public class Department {

private List<Professor> professors;
private University university;

Department(University univ){
    this.university = univ;
}

public void destroy(){
//It's aggregation here, we just tell the professor they are fired but they can still keep living
   for(Professor p:professors)
     p.fire(this);
   professors.clean();
   professors = null;
   }
}

public class Professor extends Person{

private String fullTitle;
private List<Department> attachedDepartments;

public void destroy(){
}

public void fire(Department d){
    attachedDepartments.remove(d);
    }
}


public class Student extends Person{
}

public abstract class Person{
  
   String name;
   String surname;
}

There is more explanation of differences between inheritance and composition in following article.