Refactoring Day 8 : Replace Inheritance with Delegation

All too often inheritance is used in the wrong scenarios. Inheritance should only be used in logical circumstances but it is often used for convenience purposes. I’ve seen this many times and it leads to complex inheritance hierarchies that don’t make sense. Take the following code:

   1: public class Sanitation
   2: {
   3:     public string WashHands()
   4:     {
   5:         return "Cleaned!";
   6:     }
   7: }
   8:  
   9: public class Child : Sanitation
  10: {
  11: }

In this instance, a Child is not a “Sanitation” and therefore doesn’t make sense as an inheritance hierarchy. We can refactor by initializing an instance of Sanitation in the Child constructor and delegating the call to the class rather than via inheritance. If you were using Dependency Injection, you would pass in the Sanitation instance via the constructor, although then you would need to register your model in your IoC container which is a smell IMO, you get the idea though. Inheritance should ONLY be used for scenarios where inheritance is warranted. Not instances where it makes it quicker to throw down code.

   1: public class Sanitation
   2: {
   3:     public string WashHands()
   4:     {
   5:         return "Cleaned!";
   6:     }
   7: }
   8:  
   9: public class Child
  10: {
  11:     private Sanitation Sanitation { get; set; }
  12:  
  13:     public Child()
  14:     {
  15:         Sanitation = new Sanitation();
  16:     }
  17:  
  18:     public string WashHands()
  19:     {
  20:         return Sanitation.WashHands();
  21:     }
  22: }

This refactoring comes from Martin Fowlers Refactoring book. You can view the original refactoring here

This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Sean Chambers

I am a Senior software developer from Palm Coast, Florida. An advocate of Domain Driven Design, Behavior Driven Development, creator of FluentMigrator and community activist. I am married to my beautiful wife Erin and am the proud father of two wonderful children. I currently reside at ACI, a local insurance industry/mortgage software company that excels in creating solutions using Agile methodologies.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://thomaseyde.blogspot.com Thomas Eyde

    This is a very useful refactoring. But, as always, there are these icky corner cases: I usually end up in the need of this refactoring, when I create new, but similar classes.

    At first, it makes perfectly sense to extract super class. It’s not until later, when I discover an unfortunate mix between orchestration and implementation, I see that delegation will make clearer code.

  • Scott Sherin

    Your example would be better refactored into an interface. Also why are you using a private property instead of just a private field? It’s good to make all public variables into properties so if you need the flexibility later you don’t break references. Private fields will have no references outside your class so you can refactor them into properties if needed.

    The original example gets the idea across much better than this one.

  • http://javastart.pl/ Slawek Ludwiczak

    extremely useful posts about refactoring, thanks Sean! :)