In a previous post we illustrate how inheritance can help to refine the behavior of a particular case. In this post we’ll take a look at a different approach.

Composition over inheritance

In the Gang of 4 book, they advise to use composition over inheritance. Composition is a technique that breaks an object overall behavior in smaller objects each tasked with an aspect of it. This allows for better reuse and a more maintainable codebase.

Let’s see how it works.

Refactoring from an inheritance hierarchy to a composition model

Identify the aspects of the behavior

The first thing we’re going to do is to identify the steps of the behavior being overriden.

public virtual decimal CalcBonus(Vendor vendor)
{

     decimal bonus = 0;

     bonus = washMachineSellingBonus(vendor);

     bonus += blnderSellingBonus(vendor);

     bonus += stoveSellingBonus(vendor);

     return bonus;

}

In this case these would be washMarchineSellingBonus, blenderSellingBonus and stoveSellingBonus. It’s worth mentioning that you’ll find code where the steps are not as clearly seen as in this example. Nevertheless, they’re still there. Every algorithm is just a bunch of steps in a certain order.

Create abstractions as needed

In our example the washMarchineSellingBonus, blenderSellingBonus and stoveSellingBonus are, as the name describes, bonuses. We can make this implicit abstraction explicit by creating an interface to represent it:

public interface Bonus
{
  decimal Apply(Vendor vendor);
}

public class WashMachineSellingBonus:Bonus {…}

public class BlenderSellingBonus:Bonus {…}

public class StoveSellingBonus:Bonus {…}

By doing this, we can have the calculator object with the responsibility to decide which bonuses will apply and keep track of the bonus amount while using the command pattern to contain each bonus calculation logic.

public class BonusCalculator()
{
  List<Bonus> bonuses = new List<Bonus>();

  public BonusCalculator()
  {
    bonuses.Add(new WashMachineSellingBonus());
    bonuses.Add(new BlenderSellingBonus ());
    bonuses.Add(new StoveSellingBonus ());
  }

  public decimal CalcBonus(Vendor vendor)
  {
   return bonuses.Sum(b=>b.Apply(vendor));
  }

}

So far, so good. But what’s the real benefit of this?

Inject behavior at runtime

If we apply the Dependency Inversion Principle, something interesting happens.

Public class BonusCalculator()
{
  List<Bonus> bonuses = new List<Bonus>();

  public BonusCalculator(IEnumerable<Bonus> bonus)
  {
    bonuses.AddRange(bonus);
  }

  public decimal CalcBonus(Vendor vendor)
  {
    return bonuses.Sum(b=>b.Apply(vendor));
  }
}

Now our BonusCalculator class becomes a mere container. This means that the behavior must be setup somewhere else. If needed the definition of the bonus calculator can now be hosted outside the code, like in a configuration file.

public class BonusCalculatorFactory()
{

   public BonusCalculator GetBonusCalculator(string region)
  {
   //Lookup the configuration file or a database or webservice and get the Bonuses 
     that apply to this particular region 
   }

}

The idea here is that you can now modify the behavior of the BonusCalculator without the need of a hierarchy tree.

Advantages over inheritance

The main advantages of using composition are

• Changing behavior can be done at runtime without a need to recompile the code.
• You don’t have the fragile base class problem anymore.
• You can easily add new behaviors (in the example just implement the Bonus interface)
• You can compose behaviors to create more complex ones

Let’s take a quick look at this last point.

Mix and match to create new behavior

Let’s create a composed bonus object. We can reuse the template functionality from the bonus calculator.

public class ExtraBonus(): BonusCalculator, Bonus
{
  public decimal Apply(Vendor vendor)
  {
    decimal theBonus = CalcBonus(vendor);
    return theBonus > 2000? theBonus * 1.10 : theBonus;
   }

}

Final thoughts

One of the things that I like about using composition, is that it forces you to decompose a problem to its simplest abstraction, allowing you to use this as a building block to create complex behavior and great flexibility at runtime. Now is time for a revelation: the actual text in the GoF book reads

  Favor object composition over class inheritance

It’s not my intention to explain the reasons behind this principle on this post, but the hint is on the words object and class. Think about it and let me know your observations.

The 2 sides of the coin

There are 2 aspects to any software piece: a static and a dynamic one, the former being the code and the latter being the execution of that code. The static part deals with the structure of the software while the dynamic part deals with the behavior of the software. This duality in the software is often ignored by a lot of developers, yet is there and its effects are tangible.

The structure and behavior relationship

There is a strong relationship between structure and behavior. The behavior is conditioned to the structure represented in code. You can have a rigid structure, that is, a structure that don’t allow the change of behavior without any changes to itself. The opposite is a flexible structure that allows changes to behavior without changing the structure itself.

Structure vs Code

It’s important to understand that code is not the same as structure. You can change the code without changing the structure of the software. Renaming a variable, even changing a variable, are changes that do not affect the structure of the software. The structure is more of a conceptual model, coupled with some conceptual mechanisms that is implemented by a programming language in the form of code. The way the conceptual model is defined will be affected by the programming paradigm used by the developer. You’ll come to different models/structures using different paradigms. Also the conceptual mechanisms will differ from one paradigm to another and in some cases from one language to another.

The case against switch

Put simply the purpose of polymorphism is to create a flexible structure that allows the software to change it’s behavior without changing the structure. There may be changes to the code, but not to the structure.

Consider the following code:

public enum EmployeeType
{
    Manager, Worker
}

public struct Employee
{
   public string ID {get; set;}
   public string FirstName {get; set;}
   public EmployeeType Type {get; set;}
}

public void MakePayment(Employee employee)
{
    decimal wage = 0;
    switch(employee.Type)
    {
      case EmployeeType.Manager:
        wage = 30m;
      break;
      case EmployeeType.Worker:
        wage = 10m;
      break;
    }
   decimal payment = wage * getWorkedHours(employee.ID);
...
}

Suppose we want to add a new employee type, Janitor. To make the software make payments to the Janitor (change in behavior) we would need to add a Janitor value to the EmployeeType enum and modify the switch to accommodate the new value. This is a rigid structure: you need to tweak it to make it learn new tricks. This is a typical procedural style (using C#).

The worst part of the code above is that by changing the Employee type from struct to class and putting the MakePayment procedure inside a class (most of the time as an static method) an lot of developers believe that they are now doing OOP.

Let’s see how this would look like from an OOP paradigm.

public interface Role
{
   decimal GetWage();
}

public class Manager: Role
{
   public decimal GetWage() { return 30m;}
}

public class Worker: Role
{
   public decimal GetWage() { return 30m;}
}

public class Employee
{
   Role _role;

   public Employee(Role role){
      _role = role;
   }

   public string ID {get;}
   public decimal Wage{ get{ return _role.GetWage(); }}
}

public class Timesheet
{
   public bool Pay(Employee employee)
   {
      decimal payment = employee.Wage * getWorkedHours(employee.ID);
      ...
   }
}

So in this code, if you wanted to add a Janitor employee, all you have to do is to create a new Role class that represent the Janitor role. And that’s it. That’s a code change, not a structural one. The price for this flexibility is indirection. Now there are a lot of classes, each one representing a case in the switch. That’s how we deal with branching in OOP. And that’s why OO software tends to be way more flexible than procedural software.

Final words

I hope this helps making the point clear. I tried keeping it simple, so maybe the example may look silly. I would like to say that polymorphism is not a characteristic of OOP alone: C allowed to define some sort of interface for a function and the languages in the Functional programming paradigm make heavily use of it too. Even when the form may vary, the idea it’s almost always the same: decouple dependencies and allow the creation of a flexible software structure, making it resilient in the face of change.

One of the pillars of object-oriented programming is the inheritance or the ability to create hierarchies of objects where you are refining or modifying certain behavior.  For the sake of an example, imagine a company that sells washing machines, stoves and blenders. To motivate their vendors, they have a bonus system that works in the following way:

All vendors have a sales quota. If 25% of sales are coming from washing machines, the seller gets a bonus of 15% of their salary. If at least 50% of the sales come from selling blenders, then receives a bonus of 30% of their salary. Finally if it achieves 25% of its share selling stoves gets a bonus of 20% of their salary.

Now, suppose that these vendors are distributed in the areas north, East and South. Vendors in the southern area have an additional 10% bonus if they exceed the sales quota.

We could represent it in the following way:

Then we have a class BonusCalculator. Objects of this class contain all the rules to calculate the bonus of any vendor. One way of implementing this might be something like:

public interface Vendor
{
   bool SalesPercentAchieved(double percent, string productLine);
}


public class BonusCalculator
{
  public virtual decimal CalcBonus(Vendor vendor)
  {
	  decimal bonus = 0;
	  bonus = washMachineSellingBonus(vendor);
	  bonus += blnderSellingBonus(vendor);
	  bonus += stoveSellingBonus(vendor);
	  
	  return bonus;
  }
  ...
}

However for vendors in the South, we have an additional rule to all others.

public class SouthernBonusCalculator:BonusCalculator
{
   override CalcBonus(Vendor vendor)
   {
	   decimal bonus = base.CalcBonus(vendor);
	   bonus + = overSellingBonus(vendor);
	   return bonus;
   }
   ...
}

That’s it. Just use the correct object to calculate the bonus.

void main() {
   List<Vendor> vendors = getVendors("North");
   vendors.AddRange(getVendors("Eastern"));

  var calculator = new BonusCalculator();
  for each(var vendor in vendors)
 {
    decimal bonus= calculator.CalcBonus(vendor);
    Console.WriteLine (bonus);
 }
 
 calculator = new SouthernBonusCalculator();

 List<Vendor>SouthernVendors= getVendors("South"); 
 for each(var vendor in SouthernVendors)
 {
  decimal bonus= calculator.CalcBonus(vendor);
  Console.WriteLine (bonus);
 }
}

Simple. This code leaves much to be desired but we will go adjusting it later.

Now I would like to point out that there’s no properties in the diagram nor in the code.
I did this deliberately to place emphasis on a fundamental principle: inherits it’s all about the behavior, not the data. In other words we use inheritance when we have an object that has a method that you want to adjust a bit to your needs, not when we want to reuse data. That is a common mistake. It comes from the relational databases mindset, which is reduce the duplication of data. In the case of object-oriented programming, it is reducing duplication of methods. Don’t be afraid to repeat data on different objects.

Well that is all for today, next time we will see the meaning of the phrase “favor composition over inheritance” and how that can help us improve the code for this example. Until then.