"Favor Composition over Inheritance" Is this Correct ???

You must have heard or read "Favour Composition over Inheritance" from may people, many blogs and books.  Here goes my opinion on the same...

Anyone who had worked on .NET framework to build applications has extensvily used both Inheritance as well as Composition. When a class object is being referenced by the another class object, it forms the parent/child hierarchy, where the object being referenced is the object of sub-class and the object which is holding the the referenced object is the super-class object, and this parent-child hierarchy is refereed as Inheritance. When a class uses another object to provide some or all of its functionalities then it's refereed as Composition. 

Whenever Inheritance is being discussed, knowing or unknowingly Composition comes into the picture. Lets understand both the concepts:

• Both supports code reuse
• Composition - The purpose of it is to make wholes out of parts using code reuse. 
• Inheritance - The purpose of it is to make parent-child hierarchy to reuse code (common code defined in parent class). 
• "Is A" and "Has A" Relationship 
• Composition is a "Has A" relationship as the the class owns the object of another class.
• Inheritance is a "Is A" relationship as the sub-class is also a type of super-class hence the object of super class can be used as reference object to hold the object of sub-class.
• Coupling
• In case of composition the class object is been used directly by the another class, so the reusable class is robust.
• In case of Inheritance, the super-class doesn't know anything about the sub-classes so any changes goes into the sub-classes there is no change in the behaviours of super-class but the sub-class knows about the super-class as it inherits all its behaviours so any changes goes into the super-class the sub-classes may get affected which makes a tight coupling between them.
• Test-ability
• Composition provided more flexibility for testing as its is easy class to mock objects used inside the class.
• In case of Inheritance you will need the base class (super-class). Since the derived classes (sub-classes) are tightly coupled with the base class (super-class) it become slightly difficult to mock derived class objects.
• In case of TDD mocking Composition are far much faster and easier than mocking derived classes.

Many say that go with composition when you need multiple functionalities in a class, as you can't inherit from more than one class in .NET. But what I believe is, if you have only this reason (a class can't inherit from multiple base classes) to go for Composition then you don't have to as we can achieve this by making class implement multiple interfaces.

Both Inheritance & Composition are useful while developing applications. Just that you need to know when to use what? Below are the steps I follow while selecting Inheritance or Composition.

• First Approach:
• Use Inheritance when you want to reuse the class without modifying any of its behaviours. Basically If sub-class is adding functionality to the base class go with Inheritance, if sub-class is removing behaviours from the super-class, question inheriting from super-class.
• Second Approach:
• Use Inheritance when you have "Is A" relationship like, a car "is a" vehicle. 
• Use Composition when you have "Has A" relationship like, a car "has an" engine. 

DIP vs DI vs IoC vs SL

Whenever DIP is discussed, a lot of developers confuse this with DI and IoC. So today we are going to see how these three are different from one another.

• DIP - Dependency Inversion Principe
• Its a principle which says 
• High level modules should not depend on low level modules. Both should dependent upon abstraction.
• Abstraction should not depend upon details. Details should depend on abstraction.
• It never say how this principle can be achieved.

• IoC - Inversion of Control
• A programming style where a framework or run-time controls the flow.

• DI - Dependency Injection
• A software Design Pattern of injecting a class's dependencies into at run-time.
• DI uses a builder object to initialize objects and provide the required dependencies to the object. 
• There are three ways to achieve this
• Constructor Injection
• Setter Injection (Property Injection)
• Interface Injection

• SL - Service Locator
• Introduces a locator object that, objects use to resolve dependencies.

DIP - Dependency Inversion Principle - Example

In previous post we covered what is DIP. Here I am going to show one more example of DIP.

Lets see a real- time example, we all know that whenever a bill is printed, an invoice is required to be generated and whenever an invoice is generated a bill must be printed. Lets assume that we have two classes Bill and Invoice as below.

When the below code is executed, we get the stack overflow error.

Now how do we solve this issue? This is where DIP comes into the picture, where we inject the dependencies to the dependent object. See the below code how the dependencies are injected to resolve stack overflow issues.

What we saw in above example is to achieve DIP using Constructor injection. 

PS: DIP is just the principle which requires that all your code's entities to depend only on the details they really need. DI is a process of passing the "abstract details" to the entity that really needs these derails. 

DIP - Dependency Inversion Principle

DIP says - The high-level modules/classes should not depend upon low-level modules/classes. Both should depend upon abstractions. Secondly, abstractions should not depend upon details. Details should depend upon abstractions.

It means that if a class has dependencies on other classes, it should rely on dependencies' interface in place of their concrete types. Basically it helps in developing loosely coupled code.

DIP is some way related to Dependency Injection (DI) pattern but it doesn't imply Dependency Injection. DIP just says that higher layers of your application should not directly depend on lower layers. DIP doesn’t say anything about how higher layers know what lower layer to use. This could be done by using Dependency Injection or Service Locator patterns.

Let's understand DIP with an example: Think of an application which has 4 layers, Presentation Layer, Application Layer, Business Layer and Data Access Layer. The Presentation layer is the highest layer and directly depends on or communicates with the Application Layer. The Application layer is higher level than Business Layer and depends on or communicate with the Business Layer and so on. 

When DIP is applied this relationship between layers are reversed. The Presentation Layer defines the abstractions it needs to interact with the Application Layer.  The Application Layer defines the abstractions it needs to interact with the Business Layer. The Business Layer defines the abstractions it needs to interact with the Data Access Layer. Basically the higher layer defines the abstraction and lower layer implements those abstractions.

Presentation Layer ----> Services Layer -----> Business Components Layer ----> Data Access Layer

DIP may put abstraction in the layers defining them, for example Presentation Layer contains Presentation Layer logic and the Service Layer Abstractions (abstract classes and interfaces). The Services Layer contains Service Logic and Business Layer Abstractions (abstract classes and interfaces) and so on. In this case of DIP application the Data Access Layer depends upon the Business Layer, the Business Layer depends on the Service Layer and the Service Layer depends on the Presentation Layer. The dependencies (references) are inverted hence the name of the principle.

I don't follow the above approach in my projects what I do instead is define Presentation, Services, Business and Data Access Layers as different assemblies. I also make Interfaces as different assemblies like Service Interfaces, Business Interfaces, and Data Access Interfaces.   

Since the layers interacts with each other through interfaces, the second intent (abstractions should not depend  on details. Details should depend on abstractions) of the DIP is also full-filled.  The best part about this principle is, it makes the code unit testable, like in the above example each layer can be tested independently.

Lets see DIP with an example, lets assume that we have a high level class called Manager class which represent a person that manages the workers and a low level class called Worker which represents the person a Manger class manages.

public class Worker {

   public void Work()

   {

        // working...

   }

}

public class Manager {

   private IList<Worker> objWorkers;

   public Manager(List<Worker> workers)

  {

          objWorkers =  workers;

  }

   public void Manage()

  {

        foreach (var worker in objWorkers )

             worker.Work();

   }

}

Let's say now few specialised workers are being introduced. We created a new class SuperWorker for this.

public class SuperWorker {

   public void Work()

   {

        // working...

   }

}

Now will have to be modified Manager class to accommodate SuperWorker class, which is going to break OCP. So how should we resolve this issues? This is where the DIP comes into the picture. Now create and IWorker interface and make Manager use IWorker instead of Work class. 

public interface IWorker{

    public void Works();

}

public class Worker : IWorker {

   public void Work()

   {

        // working...

   }

}

public class SuperWorker : IWorker {

   public void Work()

   {

        // working...

   }

}

public class Manager {

   private IList<IWorkable > objWorkers;

   public Manager(List<IWorkable > workers)

  {

          objWorkers =  workers;

  }

   public void Manage()

  {

        foreach (var worker in objWorkers )

             worker.Work();

   }

}

Let's say now a Robot is being introduce the only thing we need to do is make Robot implement the IWorker interface & no additional changes in the existing classes.

public class Robot: IWorker {

   public void Work()

   {

        // working...

   }

}

ISP - Interface Segregation Principle

ISP says - Many client-specific interfaces are better than one general-purpose interface. 
(The clients should not be forced to implement interfaces they don't use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module.)

This means that create the interfaces such a way that it is closely related to the code that uses it than the code which is going to implement it (Basically it says that define interfaces based on the methods which clients need than which method class implements). So that clients are not forced to implement the interfaces which they do not use.

Basically ISP is nothing but Interface Re-engineering.  

Let's see ISP with an example, suppose we have an application to print Documents and PDFs, we can print the Documents and PDFs either in colour or no-colour.

interface IPrint{
     public void Print();
     public void SetColour();
}

class Document : IPrint{
  // interface or other implementation goes here
}

class PDF: IPrint {
  // interface or other implementation goes here

}

Lets say now a new requirement comes to add the TextDocument. As we already have IPrint interface we can ask TextDocument to implement the interface IPrint but then the TextDocument class doesn't need SetColour() method because text are never required to be printed in colour. How do we over come this issue? This is where the ISP comes into the picture.

First lets try to divide IPrint interface to two interface as below:
interface IPrint{
   public void Print();
}

interface IColour {
   public SetColour();
}

Then ask new class TextDocument to implement IPrint() and existing classes to implement IColour as well as IPrint. Well, this would be wrong as it violates OCP in existing Document and PDF classes (since we are modifying them to implement the new interface). We shouldn't be modifying the exiting classes, so how should we resolve this issues now?

Well, this can be done easily, by introducing a new interface IBasePrint and moving Print() method in it and making interface IPrint and class TextDocument to implements interface IBasePrint.

interface IBasePrint{
    public Print();
}

inteface IPrint : IBasePrint
{
     public SetColour();
}

class TextDocument: IBasePrint
{
  // interface or other implementation goes here
}

PS: Like Classes, each interface should have a specific purpose/responsibility (refer to SRP). Don't force the class to implement an interface when object doesn't share the purpose. The larger the interface, the more likely it includes methods that are not required by all implementer. 

LSP - Liskov's Substitution Principle

LSP is an extension to OCP and it says - Derived class (sub class) must be completed substituted for it's base class (parent class).

This means that we must ensure that new derived classes extend the base classes without changing their behaviour.

See the example explained in OCP where Rectangle, Circle, Square are being substituted for Shape class without changing it's behaviour.  


Example where LSP is violated: 

• Lets say we have an application which uses Rectangle class as described below:

• The application works well and installed in may sites. Lets say one day user demands to have Squares along with Rectangles in the application. In mathematics a Square is an specialisation of a Rectangle which makes an "IS A" relationship, and makes us model this with an Inheritance. So in our code we made Square inherit from Rectangle as below. 

• The SetWidth() and SetHeight() methods are inappropriate for a Square as the width and height of the square are identical. This is the significant clue that there is a problem with the design. However, there is a way to subside this as shown in below code:

• Lets say we have a method Test() as below and we pass reference to Square object in this method, the Square object will be corrupted because the height won't change. This is a clear violation of LSP, function Test() doesn't work with for derivatives of its' arguments. The reason for this is SetWidth() and SetHeight() are not declared as virtual in Rectangle class.

• We can fix this easily as shown in below code. However, when the creation of a derived class causes us to make changes to the base class, it often implies that the design is faulty. Indeed, it violates the Open-Closed principle.  

• So far it's good, lets say we have a method TestArea() as shown below. This method calls SetWidth() as well as SetHeight() members considering it is a Rectangle. The assertion works fine when an object of Rectangle class is passed but not for an object of Square class. Since, this methods takes reference of type Rectangle but cannot operate upon Square, which violates LSP. Making Square class derived from Rectangle class has broken method TestArea(), as we may have to put a conditional check to determine if the object passed is not the type of Square for assert to pass, which in-turn violated the OCP.

So what went wrong? in above example. Isn't a Square a Rectangle? Doesn't a "IS A" relationship hold between them?  No! A square might be a rectangle, but a Square object is not a Rectangle object. This is because the behaviour of a Square object is not consistence with the behaviour of a Rectangle object. It's the behaviour that software is really all about.

The LSP makes clear that in OOD the "IS A" relationship pertain to behaviour. Not intrinsic private behaviours, but extrinsic public behaviour; the behaviours clients depends upon. In order for the LSP to hold, and with it the Open-Closed principle, all derivatives must conform to the behaviour that clients expect of the base classes that they use.

There is a strong connection between the LSP and Design by Contract. Design by Contract says, that methods of a class has pre-conditions and post-conditions. The preconditions must be true in order for the method to execute. Upon completion, the method guarantees that the post-condition will be true. 

The rules for precondition and post-condition for derived class says that while redefining a method in derived class, you may only replace it's precondition by a weaker one, and its post condition by a stronger one.  In other words, when using an object through its base class interface, the user knows only the preconditions and post-conditions of the base class. Thus, derived objects must not expect such users to obey preconditions that are stronger then those required by the base class. That is, they must accept anything that the base class could accept. Also, derived classes must conform to all the post-conditions of the base. That is, their behaviours and outputs must not violate any of the constraints established for the base class. Users of the base class must not be confused by the output of the derived class.

OCP - Open Closed Principle - Example

Example of OCP - A fruit selling application which has SalesManager class as below:

The problem with the above SalesManager code is that, whenever a new fruit is being introduced, the method SellFruits() needs to be modified which breaks OCP. So now, how do we resolve this issue? We can do something like below code:

Now, if a new fruit is being introduced, we don't need to modify method SellFruits() of SalesManager class, we just have to create a new class and make that class implement IFruit interface.

The fruit checking logic need to be moved to some place, in this case it is being moved to the class who is making use of the class SalesManager. So whenever a new fruit is being introduced only this par of the code need to be modified.

Well, the above code can be fixed using reflection, if the Assembly name is known and the fruit name resembles the fruit class created. Even if there is a new fruit introduced, there is no change required in the code if the code is written as below using reflection. 

Basically while using the above code we will be having classes like below, and based on the fruitName variable value, the instance of that class will be created during run-time.

• For apple - OCP.Apple.
• For orange OCP.Orange
• For pineapple - OCP.Pineapple
• For banana - OCP.Banana

OCP - Open Closed Principle

OCP says -  A software module/class is open for extension and closed for modification.

"Open for extension" means we need to design our module/class in such a way that the functionalities can be added only when new requirements are generated. 
"Close for modification" means we need not alter the existing class (which have already developed and has gone through unit testing) until a bug comes.

Lets see OCP with an example, suppose we have a rectangle class with height and width and our application needs to calculate the total area of the collection of rectangles. By applying SRP, we cannot add total area calculation code inside Rectangle class, so I have created a new class call ed AreaCalculator. 

public class Rectangle {
     public double Width { get; set; }
     public double Height { get; set; }
}

public class AreaCalculator {
    double area;
    public double TotalArea(List<Rectangle> rectangles)
    {  
        foreach(var item in rectangles) {
            area+= (item.Width * item.Height);
        }
        return area;
     }
}

Lets say now we need to extend our application to support circle. Now we have an issue because the AreaCalculator just takes the list of type Rectangle, but we can change this method a bit to accommodate Circle as below:

public class Circle{
    public double Radius { get; set; }
}

public class AreaCalculator {
    double area;
    public double TotalArea(List<Object> shapes)
    {  
        foreach (var item in shapes) 
        {
           if (item is Rectangle)
           {
                var rectangle = (Rectangle) item;
                area+= (rectangle .Width * rectangle .Height);
           }
          if (item is Circle)
          {
                 var circle = (Circle) item;
                area+= (circle.Radious * cirlce.Radious * Math.PI);              
          } 
        }
        return area;
     }
}

Let's say now we need to extend our application to accommodate Tingle, Square and other shapes, we will have to add new if conditions in TotalArea method which makes class AreaCalculator as open for modification  (which violates OCP). To overcome this problem we can do the following:

public abstract class Shape {
     public abstract double Area();
}

public class Rectangle : Shape {
     public double Width { get; set; }
     public double Height { get; set; }
     public override double Area(){
           return (Width *  Height);
     }
}

public class Circle : Shape {

    public double Radius { get; set; }    

    public override double Area()

    {

           return (Radius *  Radius * Math.PI);

     }

}

public class Square : Shape {

    public double Side{ get; set; }

    public override double Area()

    {

           return (Side *  Side);

     }

}

public class AreaCalculator {

    double area;

    public double TotalArea(List<Shape> shapes)

    {  

        foreach (var item in shapes) 

        {

            area += item.Area();

        }

        return area;

     }

}

Whenever a new shape is introduced the new shape class has to derive from "Shape" abstract class and we don't need to modify AreaCalculator class. 

Now our code is following SRP as well as OCP.  Awesome! Isn't it?

SRP - Single Responsibility Principle

SRP says - Every software module should have only one reason to change.

This means that a class or similar structure should have only one job to do. It doesn't mean that a class should have only one method or property, it can have many members (methods and properties ) as long as they related to single responsibility.

Swiss knife is the real-life example where SRP is broken, that's because the tool requires alteration if any one of the item needs changes.   

Lets see SRP with the example below:
public class UserService {
      public void Register()
     {
          // validate email
          // Register User
         // send confirmation mail to user
     }

      public bool ValidateEmail()
     {
     } 

      public bool SendMail()
     {
     }
}

We have a UserService with Register method which registers the user after validating e-mail ID and then sends the e-mail confirmation to the user. In this implementation of UserService, it violets SRP, since it's not only does the user registration but also the email validation and sending confirmation e-mail to user. To overcome this issue create one more class and move ValidateEmail() and SendMail() method to it.

public class EmailService()
{
      public bool ValidateEmail()
     {
     } 

      public bool SendMail()
     {
     }
}

Now the UserService class looks as below:
public class UserService {

      public void Register()
     {
          // validate email using EmailService
          // Register User
         // send confirmation mail to user using EmailService.
     }     
}
  
Advantages:

• Gives a good way to identify classes at the design phase of an application and makes you think of all the way a class can change.
• Reduces Code complexity.
• Improves Readability.
• Reduces Coupling.
• Code gets better chance of cleanly evolving.

PS: SRP is not about code-reuse.

S.O.L.I.D

Design Principles provides ways to overcome most of the software design problems. SOLID principles are complied by Robert C. Martin in the 1909s. These principles provide us to move from tightly coupled code to loosely coupled code and encapsulate real needs of business properly. SOLID is acronym for following:

• S: Single Responsibility Principle (SRP) -  Every software module should have only one reason to change.

• O: Open Closed Principle (OCP) -  A software module/class is open for extension and closed for modification.

• L: Liskov's Substitution Principle (LSP) - A derived class (sub class) must be substituted for it's base class (parent class).

• I: Interface Segregation Principle (ISP) -  The clients should not be forced to implement interfaces they don't use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module.

• D: Dependency Inversion Principle (DIP) - The high-level modules/classes should not depend upon low-level modules/classes. Both should depend upon abstractions. Secondly, abstractions should not depend upon details. Details should depend upon abstractions.

I will be covering in depth details of each of these principle in my upcoming posts.

A "Bad Design" ???

You might have presented plenty of software design for peer review and the peer might have certainly asked you this question: “Why’d you do it that way?” and also might have told you this: “That’s not the way I would have done it”. 

Well, this has happened to me, and I am sure it might have happened to many other engineers out-there. Everyone has their own criteria for defining what is a "Bad Design", that one may agree or may not agree, but all will agree that any software that full-fills it's requirement but has following three traits has a "Bad Design":

• Rigidity -  It is hard to change because every change affects too many other parts of the system. A design is called rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules.
• Fragility - When you make a change, unexpected parts of the system break. Fragility is the tendency of a program to break in many places when a single change is made. Simple changes to one part of the application lead to failures in other parts that appear to be completely unrelated. 
• Immobility -  It is hard to reuse in another application because it cannot be disentangled from the current application. A design is immobile when the desirable parts of the design are highly dependent upon other details that are not desired. 

Basically, the inter-dependency between modules makes a design rigid, fragile and immobile.

Well, we can say that,  it would be difficult to demonstrate that a piece of software that exhibits none of the above traits (i.e. it is flexible, robust, and reusable) and that also full-fills all its requirements, has a bad design. Thus, we can use these three traits as a way to decide if a design is “Good” or “Bad”.