Object oriented design principles III

Hi Everyone, Today I am going to explain about two remaining OOP design principles I have mentioned in my first blog post.

Interface Segregation Principle-ISP

 

"Client should not force to implement interfaces they do not want to use. Instead of one common large interface many small interfaces are preferred to use."

"Many single purpose interfaces are better than one common purpose interface."

Basically ISP states,

No client should be forced to depend on methods it does not want to use.

Now I will explain what ISP really means. When we create an interface we can define several methods in it. Then when we are going to use this interface we must implement each and every method in it. Otherwise it will give some compilation errors. But sometimes client does not want to implement all methods in the interface. Such kind of situations client should not force to use methods it does not want to use .That is what interface segregation principle said.

I will explain this using a simple example with object oriented programming.

    public interface IBird

    {

        void Eat();

        void Drink();

        void Fly();

        void Swim();

    }

    public class parrot : IBird

    {

        public void Eat()

        {

            //Do some thing

        }

        public void Drink()

        {

            //Do some thing

        }

        public void Fly() 

        {

            //Do some thing

        }

        public void Swim()<=Parrot doesn't swim ,here we force it to swim

        {

            //Do some thing

        }

    }

    public class Duck : IBird

    {

        public void Eat()

        {

            //Do some thing

        }

        public void Drink()

        {

            //Do some thing

        }

        public void Fly() <=Duck doesn't fly,here we force it to fly

        {

            //Do some thing

        }

        public void Swim()

        {

            //Do some thing

        }

    }

There is an interface called IBird and it has four method definitions such as Eat(),Drink(),Fly() and Swim() .There are two classes, Parrot and Duck .Both classes are inherited by IBird interface. So both classes happened to implement four methods define in the interface. But you all know Duck does not fly and parrot does not swim. But in here duck force to fly and parrot force to swim .So this is violating interface segregation principle.

We will see how to ensure interface segregation principle in this situation. To do it we have to create two different interfaces which are also inherit from IBrid interface. Below code snippet will show this properly.

    public interface IBird

    {

        void Eat();

        void Drink();

    }

    public interface ISwimmingBird : IBird

    {

        void Swim();

    }

    public interface IFlyingBird : IBird

    {

        void Fly();

    }

    public class parrot : IFlyingBird

    {

        public void Fly()

        {

            //Do some thing

        }

        public void Eat()

        {

            //Do some thing

        }

        public void Drink()

        {

            //Do some thing

        }

    }

    public class Duck : ISwimmingBird

    {

        public void Swim()

        {

            //Do some thing

        }

        public void Eat()

        {

            //Do some thing

        }

        public void Drink()

        {

            //Do some thing

        }

    }

Here Parrot and Duck implements only methods they want to use .They do not force to use unwanted methods. That how we ensure ISP and we do not violate the principle.

Like each and every principle ISP is also a one which require additional time and effort in software design. But this provides more flexibility and more meaningful software design.

Dependency Inversion Principle-DIP

"Instead of lower level modules defining an interface that higher level module depend on, higher level modules define an interface that lower level module implement."

Let’s try to understand DIP using a real world example. Think you have several devices like phone, camera etc. These devices use cables to connect with charger or PC. They have ports or jacks to connect with charger or PC. Then if I ask, who is defined the port or jack? Cable or device?

You will definitely answer it as device. Yes, you are correct .This means port never decides what will be the device and devise decide what will be the port. In the example device is higher level module and cable is lower level module .So this shows dependency inversion principle.

This is similar to software design. Higher level module defines the interface and lower level module implements that interface and lower level module doesn’t define the interface like cable doesn’t define port or jack.

DIP according to Bob Martins definition

“A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
 B. Abstractions should not depend upon details. Details should depend upon abstractions.”

According to this higher level module should not depend on lower level modules .An abstract layer should between both layers. So both layers depend on abstraction. In abstract layer we can define interfaces to connect both layers.

When this principle is applied the higher level modules does not working directly with lower level modules. They are always using interfaces as abstract layer. 

There is a solution called IOC (Inversion of control) to ensure dependency inversion principle .I am not going to talk about it .There are lot of articles related to IOC in web. You can refer one of them to understand it.

 http://patterns.instantinterfaces.nl/current/Refactoring-and-Design-Patterns-INTRDP-IOC.html

In this article I have explained about Interface segregation principle and dependency inversion principle .I think you could get the basic idea of these two principles and you could understand how we apply these principles when you are going to design a program or application.

There are more principles other than those categorized as SOLID by uncle Bob. I am not going to describe each and every principle in detail now but they are,

·         Program to Interface Not Implementation.

·         Don't Repeat Yourself.

·         Encapsulate What Varies.

·         Depend on Abstractions, Not Concrete classes.

·         Least Knowledge Principle.

·         Favor Composition over Inheritance.

·         Hollywood Principle.

·         Apply Design Pattern wherever possible.

·         Strive for Loosely Coupled System.

·         Keep it Simple and Sweet / Stupid.

Finally we come to the end of OOP design principles session and I hope you all understand the real value of these principles and I hope you will think to apply these principles as much as possible when you are going to design and develop a program module.

“ SOLID is not a must to follow but it is a best practice in object oriented programming .It can manage changes , it can provide more flexible, maintainable, Extendable software design”