Understanding OOPS SOLID Principles

SOLID principles

Thanks to Al-Farooque Shubho’s article on codeproject

Single Responsibility Principle

“There should never be more than one reason for a class to change.”
Or, differently said: “A class should have one and only one responsibility”.

It says, “Just because you can implement all the features in a single device, you shouldn’t”. Why? Because it adds a lot of manageability problems for you in the long run.

If you have a class that has more than one reason to change (or has more than one overall responsibility), you need to split the class into multiple classes based upon their responsibility.

You surely can have multiple methods in a single class. The issue is they have to meet a single purpose. Now, why is splitting important?

It’s important because:
• Each responsibility is an axis of change.
• Code becomes coupled if classes have more than one responsibility.

We should break up the class based on its responsibilities.SRP seems to be an idea of breaking things into molecular parts so that it becomes reusable and can be managed centrally.

So, shouldn’t we apply SRP in the method level as well? I mean, we might have written methods that have many lines of code for doing multiple things. These methods might be violating SRP.

Yes, you should break down your methods so that each method does a particular work. That will allow you to re-use methods, and in case a change is required, you are able to do the change by modifying minimal amount of code.

Let’s say we have Rectangle class which implements two functionalities i.e. Calculate Area & Draw Rectangle.
So we should break this rectangle class
1. Rectangle: This class will only calculate area.
2. RectangleUI: This will inherit Rectangle class & will implement method which will draw rectangle.

Open-Closed Principle

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

At the most basic level, that means, you should be able to extend a class’s behaviour without modifying it. It’s just like I should be able to put on a dress without doing any change to my body.

Liskov’s Substitution Principle

“Subtypes must be substitutable for their base types.”
Or, if said differently:
“Functions that use references to base classes must be able to use objects of derived classes without knowing it.”

Lets consider Class Bird which implements method Fly () & Kingfisher class which will extend Bird class.

Here, the Kingfisher class extends the Bird base class and hence inherits the Fly () method, which is pretty good.
Let’s create one more class Ostrich which also extends Bird class.

Now, can it fly? No! Here, the design violates the LSP.

So, even if in real world this seems natural, in the class design, Ostrich should not inherit the Bird class, and there should be a separate class for birds that can’t really fly and Ostrich should inherit that.

Interface Segregation Principle

“Clients should not be forced to depend upon interfaces that they do not use.”

Suppose you want to purchase a television and you have two to choose from. One has many switches and buttons, and most of those seem confusing and doesn’t seem necessary to you. Another has a few switches and buttons, which seems familiar and logical to you. Given that both televisions offer roughly the same functionality, which one would we choose?

Obviously the second one with the fewer switches and buttons.

Yes, but why?

Because we don’t need the switches and buttons that seem confusing and unnecessary to us.

Similarly, suppose we have some classes and we expose the functionality of the classes using interfaces so that the outside world can know the available functionality of the classes and the client code can be done against interfaces. Now, if the interfaces are too big and have too many exposed methods, it would seem confusing to the outside world. Also, interfaces with too many methods are less re-usable and such “fat interfaces” with additional useless methods lead to increased coupling between classes.

This also leads to another problem. If a class wants to implement the interface, it has to implement all of the methods, some of which may not be needed by that class at all. So, doing this also introduces unnecessary complexity, and reduces maintainability or robustness in the system.

The Interface Segregation principle ensures that Interfaces are developed so that each of them has their own responsibility and thus they are specific, easily understandable, and re-usable.

Consider IBird Interface which defines behavior like Fly (), Walk (), Chirp (), Eat ().
Note that the IBird interface has many bird behaviours defined along with the Fly () behaviour. Now, if a Bird class (say, Ostrich) implements this interface, it has to implement the Fly () behaviour unnecessarily (Ostrich doesn’t fly).

The “Fat Interface” should be broken down into two different interfaces, IBird and IFlyingBird, where the IFlyingBird inherits IBird.

If there is a bird that can’t fly (say, Ostrich), it would implement the IBird interface. And if there is a bird that can fly (say, KingFisher), it would implement the IFlyingBird interface.

Dependency Inversion Principle

“High level modules should not depend upon low level modules. Rather, both should depend upon abstractions.”

Let’s consider a real world example to understand it. Your car is composed of lots of objects like the engine, the wheels, the air conditioner, and other things.None of these things are rigidly built within a single unit; rather, each of these is “pluggable” so that when the engine or the wheel has problem, you can repair it (without repairing the other things) and you can even replace it.

While replacement, you just have to ensure that the engine/wheel conforms to the car’s design (say, the car would accept any 1500 CC engine and will run on any 18 inch wheel).Also, the car might allow you to put a 2000 CC engine in place of the 1500 CC, given the fact that the manufacturer (say, Toyota) is the same.

In real world, Car is the higher level module/entity, and it depends on the lower level modules/entities like the Engines or Wheels.

Rather than directly depending on the Engines or Wheels, the car depends on the abstraction of some specification of Engine or Wheels so that if any the Engine or Wheel conforms to the abstraction, these could be assembled with the car and the car would run.