Open-Closed Principle

You should be able to extend a classes behavior, without modifying it.

This principle is the foundation for building code that both open and closed.

• Open for extension: This ensures that the class behavior can be extended. As requirements change, we should be able to make a class behave in new and different ways, to meet the needs of the new requirements.

• Closed for modification: The source code of such a class is set in stone, no one is allowed to make changes to the code. Abstractions and Generalisations enable the programmer to extend the behavior of a class without changing a single line of code. For example, Circles and Squares can be programmed as shapes. Then, wherever we had Dependency Injection, we would inject a Shape instance instead of an instance of a lower-level class. This would give us the luxury of adding new shapes without having to change the dependent classes’ source code.

Liskov Substitution Principle

Derived classes must be substitutable for their base classes.

We have a Rectangle a Square class that extend its. Rectangle has two methods, setWidth and setHeight set the width and height of the rectangle respectively. The problem is that the behavior for the two methods differs between the Rectangle and the Square classes. The reason for that is that a Square, by mathematical definition is a Rectangle with equal height and width. So, the two methods will change the same value, whereas for the Rectangle, they will change the width and height respectively, which are different values from each other. When we are using abstraction(Open-Closed Principle), we want the methods to behave the same for each derived class, and not differently. Square class should not be extending the Rectangle class, because the behavior of the inherited methods differs.The solution is to design by contract. What this means is that each method should have preconditions which must hold true in order before a methods executes and post-conditions after the execution of a method.

 Interface Segregation Principle

Make fine grained interfaces that are client specific.

Let’s say we had an interface called Animal, which would have eat, sleep and walk methods. This would mean that we have a monolithic interface called Animal, which would not be the perfect abstraction, because some animals can fly. Breaking this monolithic interface into smaller interfaced based by role, we would get CanEat, CanSleep and CanWalkinterfaces. This would then make it possible for a species to eat, sleep and for example fly. A species would be a combination of roles, instead of being characterized as an animal, which would not necessarily be the best description. At a larger scale, microservices are a very similar case, they are pieces of a system separated by responsibilities, instead of being a great monolith. 

 Dependency Inversion Principle

Depend on abstractions, not on concretions.

By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming.  By depending on higher-level abstractions, we can easily change one instance with another instance in order to change the behavior. Dependency Inversion increases the reusability and flexibility of our code. This principle is defined easiest by two rules:

• High level modules should not depend upon low level modules. Both should depend upon abstractions.

• Abstractions should not depend upon details. Details should depend upon abstractions.

The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction should be thought of as an abstract interaction between them. This not only has implications on the design of the high-level module, but also on the low-level one: the low-level one should be designed with the interaction in mind and it may be necessary to change its usage interface.