[C# Design Patterns] Composition Over Inheritance

This post will demonstrate the difference between using inheritance and using composition.



What is “prefer composition over inheritance”?

Sometimes, a project needs several classes that appear to be similar, but have different behavior.

In object-oriented programming, we will often handle this with inheritance. We create a base class. Then, we create sub-classes that inherit from the base class, and have the properties and functions that are unique to the sub-class.

But, that can sometimes lead to messy code.

An alternative is to use “composition”, to have a single class that can be “composed” to handle the different behaviors.


Why you would want to use it

If you were writing a game, you might have different types of monsters. The different types of monsters could be able to do different attacks – biting, kicking, or punching.

One way to build this would be to create a base Monster class, and create sub-classes for BitingMonster, KickingMonster, and PunchingMonster – with each sub-class handling the details for the different way of fighting.

But, what do you do if you have a new monster that needs to bite and kick?

Using inheritance, you might create a BitingKickingMonster. That could inherit from Monster, BitingMonster, or KickingMonster.


Inheritance versions

Let’s pretend you work at a game programming company.

You’re building a new game, and you create a Monster class, with two properties – HitPoints and AttackDamage. The code might look like this:


Then, your boss tells you the game needs to have different types of monsters. One type will attack by biting, the second by kicking, and the third by punching. So, you make the Monster class into a base class, and create three new sub-classes from it: BitingMonster, KickingMonster, and PunchingMonster.

Now, you have these classes:









The next day, your boss tells you they need new types of monsters in the game – ones that can do different combinations of biting, kicking, and punching. Because this is getting complex, you also build a Factory class, to create the different types of monster objects.

If you continue with making sub-classes, you could end up with this code:



















If you use a factory class to instantiate objects, it might look like this – instantiating the objects with the required sub-class.




Notice that we run into a problem when a new class needs to inherit from more than one base class. For example, the BitingKickingMonster inherits from BitingMonster, and duplicates the KickDamage property – because it could not also inherit from KickingMonster.

If these classes were in a real program, and not a simple demonstration, there would probably be much more duplication of properties and functions.

There is another problem. If we try to determine the “type” of an object, to determine what attacks it can perform, we can only check against the single bae class – not the second class.


After you finish creating all these classes, your boss sends you an email. Now, you need to have monsters that can also attack by spitting.

Cobras will bite and spit, camels will kick and spit, etc.

Instead of creating more sub-classes, you decide to try using composition.


Composition version

The definition of “Composition” is, “combining parts or elements to form a while”.

In this case, we will have a single Monster class, and “compose” it with the appropriate attack behavior for each type of monster.




With this Monster class, when we create a new Monster object, we “compose” its Attack options by calling the AddAttackType() function – with the AttackType, and the amount of damage the monster does with this attack.

I added a few more properties (CanBite, CanKick, and CanPunch), to make it easy to know what types of attacks a monster can perform.

This one class also has all the Damage properties in it (BiteDamage, KickDamage, and PunchDamage).

With these six properties, we can compose the Monster object to attack however we want – which we do in the MonsterFactory class below.




This is a little more complex than the previous factory, because this is where we “compose” the Monster object, to act like a BitingMonster object (or, whatever attacks the monster can perform).




In these unit tests, we can use the CanBite, CanKick, and CanPunch properties to simulated checking for the “type”, like we would in the inheritance version.


With the composition method, when our boss tells us to add a new “Spit” attack, instead of creating new classes, we would only need to:

  1. Add a new “Spitting” value to the AttackType enum in Monster.cs
  2. Add a new “CanSpit” property to Monster.cs
  3. Add a new “SpitDamage” property to Monster.cs

Then, MonsterFactory.cs can create monsters that can use the new “spit” attack.

The code might look like this:






Notice that the Camel can now kick and spit. There is also a new monster: the cobra, which can bite and spit.

To give the Camel a new attack ability, we only needed to add one line (line 53).

To add the cobra, we only needed to add it to the enum, and add a new “case” (starting at line 45) to create the cobra – by composing a monster that can bite and spit.



Where I’ve found it useful

There are two common situations when you would want to consider using composition, instead of inheritance: when you need to do multiple inheritance, and when your sub-classes start to have their own sub-classes.

These are big indicators that the composition might be a better choice.

You might also combine object composition with the Strategy Design Pattern. Instead of composing the object with property values (the attack type and damage), you could also compose it by configuring how it will perform its actions.


Source Code

The source code from these design patterns demonstrations is available at: http://scottlilly.com/GHCSharpDesignPatterns