Introduction to S.O.L.I.D Principles

 The S.O.L.I.D principle helps to design the software based on the object oriented concepts. This helps to design a software in an efficient manner with standard development and easy debugging principles.

1. Single Responsibility Principle (S.)

👉     This principle lays out that the software designers should focus their development one at a time. This suits that one use case provided by the client should analyzed at once. 

👉     It is not a good practice to work on multiple use cases since it may lead to addition of unusual complexities and loss of any specific requirements due to multiple perspectives.

💥     An best example is a class designed to print the employee details, should only focus on printing the details not calculating the salary for the employees. 

2.Open / Close Principle (O.)

👉     This principle outlines that the designed objects should reliable for extension but not unauthorized modification.

👉     The key idea is the classes and interfaces that we create should be able to withstand new relevant extensions, but it should not accept modifications if its irrelevant and not authorized.

💥     An best example is a class designed to print the employee details, should be able to add new details to the list but not delete any important details if its used by any other classes or objects.

3.Liskov Substitution Principle (L.)

👉   This principle mainly deals with the inheritance concept. It states that you should design your classes so that client dependencies can be substituted with the subclasses without the client knowing about the change.

👉    In my words this is if the sub class implement new methods or attributes which are not relevant to its super class then the liskov substitution principle is violated.

💥     An example is a class name Shape created with an attribute called length then a base class called Rectangle is created where it changes the length to irrelevant data then LSP is violated.

4.Interface Segregation Principle (I.)

👉     This is a principle that elaborates more on the end user. The main idea is if an interface is implemented we actually implement all its methods. This can be sometimes irrelevant to the user.

👉      This means although the interface contains many abstract methods the end user should not be forced to implement all those methods.

            "This is something like, take what you need not the whole in  the basket"

💥     An example is an interface which contains methods needed by both end user and the admin, where both admin the user need to implement their own and their irrelevant methods too. This type of situation interface segregation principle is violated.

4.Dependancy Inversion (D.)

👉     Higher level modules should not depend on the lower level modules, but only for the abstraction.

👉    Here highlevel modules are which much closer to the business while lower level modules are like more technical stuffs.