org_web/posts/career/solid-principles.org

SOLID Principles

• Why is SOLID principles needed?
• The following may be cases where it may not be necessary to use the SOLID principles:

The 5 SOLID principles are guidelines that makes the code more maintainable and scalable. They enhance a term known as loose coupling, which means that the components have minimal dependancies on one another. This is particularly useful as it allows for the code to be reusable, scalable, flexible, stable and maintainable.

• S - Single responsability Principle: The objective of this principle is that a class should only have one reason to change. In other words, every class should fulfill a single responsability. An example is a cashier, whose job is to scan goods, process payments and give the customers their goods. If the responsability of the cashier is also to meet with suppliers, then this violates SRP. This principle is useful as it allows us to have a clear seperation of concerns, thus allowing us to have more modular and understandable code.
• O - Open Closed Principle: The objective of this principle is to allow for software entities (such as classes, functions and modules) to be open for extension but closed for modification. What this means is that you should be able to extend a class behaviour (maybe adding more functions) without modifying it.
• L - Liskov's Substitution Principle: This principle ensures that any class that is the child of a parent class (derived) should be usable in place of its parent without any unexpected behaviour. The famous example used to explain this is a rectangle and square. A rectangle has 4 sides, the height and width can be any value. A square is a rectangle with equal width and height, so we say that the properties of the rectangle class extends into the square class. The derived class does not affect the behaviour of the parent class, therefore does not violate the principle.
• I - Interface Segregation Principle: This principle is different from the others in the sense that it applies to interfaces rather than classes. It states that you should not force any client to implement an interface which is irrelevant to them. What this means is that you should prefer having many client interfaces rather than a single general interface. For example, if a restaurant has vegetarian and non vegetarian items, the waiter should give the customer a menu card that's specific for vegetarian items. The menu should be different for different types of customers.
• D - Dependency Inversion Principle: This principle states that high level modules should not depend on low level modules, both should depend on abstractions. Furthermore, the abstractions should not depend on details. In other words, classes should rely on abstractions rather than concrete implementations. For example, in a software development team, developers depend on an abstract version control system like Git. They do not depend on the specific details about how it works internally.

Why is SOLID principles needed?

• It makes code easier to maintain. This is thanks to each class having a clear responsability (SRP).
• Allows for scalability. This is thanks to the open closed principle, allowing for new features to be added without changing existing code.
• Allows for flexibility. This is thanks to the DIP, which allows developers to change components without disrupting the whole system.

The following may be cases where it may not be necessary to use the SOLID principles:

• One off or short lived projects. This is because not all software needs long term maintenance.
• Performance critical applications. Enforcing SOLID here can result in performance bottlenecks.
• Small and self contained applications. If the system serves limited purpose, adhering strictly to the SOLID principles can lead to over engineering.

The following article explains in detail exactly when to avoid the principles: When Using Solid Principles May Not Be Appropriate