1) Single Responsibility Principle : SRP
” A CLASS SHOULD HAVE ONLY ONE REASON TO CHANGE. ”
Every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.

In any enterprise software application development when we design and develop software systems, we need to account the below factors during the development cycle.
- Maintainability
- Testability
- Flexibility and Extensibility
- Parallel Development
SOLID Principles and Design Patterns plays a key role in achieving all of the above points.
In Single Responsibility Principle,
- Each class and module should focus on a single task at a time.
- Everything in the class should be related to that single purpose.
- There can be many members in the class as long as they related to the single responsibility.
- With SRP, classes become smaller and cleaner
- Code is less fragile
2) Open Closed Principle : OCP
” open for extension, but closed for modification. “
In object-oriented programming, the open/closed principle states that “software entities such as classes, modules, functions, etc. should be open for extension, but closed for modification”.

Which means, any new functionality should be implemented by adding new classes, attributes and methods, instead of changing the current ones or existing ones.
Implementation guidelines :
- The simplest way to apply OCP is to implement the new functionality on new derived (sub) classes that inherit the original class implementation.
- Another way is to allow client to access the original class with an abstract interface.
- So, at any given point of time when there is a requirement change instead of touching the existing functionality it’s always suggested to create new classes and leave the original implementation untouched.
3) Liskov Substitution Principle: LSP
” Objects of a superclass shall be replaceable with objects of its subclasses ”
Substitutability is a principle in object-oriented programming and it states that, in a computer program, if S is a Subtype of T, then objects of type T may be replaced with objects of type S.
Which means, Derived types must be completely substitutable for their base types.
More formally, the Liskov substitution principle (LSP) is a particular definition of a sub-typing relation, called (strong) behavioral sub-typing.This Principle is introduced by Barbara Liskov in 1987 during her conference address on Data abstraction and hierarchy.
This principle is just an extension of the Open Close Principle.

4) Interface Segregation Principle : ISP
” no client should be forced to depend on methods it does not use “
This principle describe advantages of having many small interfaces based on groups of methods with each one serving one sub-module Instead of one large interface .

This principle(Interface Segregation Principle) was first used and formulated by Robert C. Martin while consulting for Xerox.
When the software grows eventually Easier to violate the concept, especially when the new requirements arise and have to add more and more functions.
Splitting larger interfaces into individual components and implementing classes that only applies to the methods are advantages of it.
case study :
- Xerox corporation manufactures printer devices.In their development process, they had to build a new printer with adding new features compared to a normal printer.They are the printer should be able to handle multiple tasks such as faxing and stapling along with normal printing tasks.
- The device software was started to be deployed .
- During the development, It became so difficult to modify even simple changes and it was much time consuming.
Solution :
- To prevent this problem Interface segregation principle was suggested by Robert C Martin.By using this principle of interface segregation above problem can be overcome.
5) Dependency Inversion Principle : DIP
” High-level modules should not depend on low-level modules. Both should depend on abstractions ”

High-level modules should not depend on low-level modules. Both should depend on abstractions. and Abstractions should not depend on details. Details should depend on abstractions.
To simplify this we can state that while 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.
Dependency Inversion Principle can be achieved by following both Open/Closed Principle and the Liskov Substitution Principle.

































