SOLID Principles
Principles that make you a better developer
Bad Architecture?
Do you think the project you currently working on is having bad architecture? If your answer is yes, then you are in the right place. Before start, we are going to see common factors of bad architecture.
Fragility
A change may break unexpected parts — if you don’t have good test coverage of your application it will be very difficult to detect the bugs.
Rigidity
Rigidity is closely related to fragility, A change may require a lot of effort because it affects several parts of the project.
Immobility
A component is difficult to reuse in another project or in multiple places of the same project because it has too many coupled dependencies.
Viscosity
Viscosity is the resistance to making a change. Instead of making a change in the appropriate place, we end up making the change in the place that provides the least resistance.
If you want to solve these problems you need a common design principle that’s SOLID.
Why SOLID?
The main purpose of SOLID is to avoid bad architecture, also you will get the following benefits when you follow these 5 principles.
- Increases code confidence: easy to extend/modify/refactor the code
- Facilitates common language: easy to understand when everybody knows about these principles.
- Isolates area that change: encapsulate the code we change often
- It makes testing easier
What are SOLID design principles?
SOLID Principles is a coding standard that developers should have a clear concept for developing applications in a proper way to avoid bad design. It was promoted by Robert C Martin and is used across the object-oriented design spectrum. When applied properly it makes your code more extendable, logical, and easier to read. This principle is an acronym of the five principles which is given below…
- Single Responsibility Principle (SRP)
- Open-Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
these are not strict rules, but just guidelines to improve the quality of your architecture.
S — Single Responsibility Principle (SRP)
“There should never be more than one reason for a class to change”
One class should only serve one purpose, this does not imply that each class should have only one method but they should all relate directly to the responsibility of the class. All the functions, methods, and properties should all work towards the same goal. When a class/method/property serves multiple purposes or responsibilities then it should be made into a new one.
Next: Check out the Single Responsibility Principle article to know more about this principle
O — Open-Closed Principle (OCP)
“Classes and Modules should be open for extension but closed for modification”
Software entities like classes, modules, functions, etc. should be extendable without actually modifying the content of the class you are extending. If you follow this principle then it is possible to modify the behavior of the code without touching a piece of original code.
Next: Check out the Open-Closed Principle artical to know more about this principle (Coming soon..)
L — Liskov Substitution Principle (LSP)
“Subclass/derived class should be substitutable for their base/parent class”
LSP states that any implementation of the interface/abstraction should be substitutable in any place that the abstraction/interface is accepted. it defines objects of a superclass shall be replaceable with objects of its subclasses without breaking the application. That requires the objects of your subclasses to behave in the same way as the objects of your superclass.
Next: Check out the Liskov Substitution Principle article to know more about this principle (Coming soon..)
I — Interface Segregation Principle (ISP)
“Clients should not be forced to depend upon interfaces that they do not use.”
This rule means that we should break our interfaces into many smaller ones, so they better satisfy the exact needs of our clients. Also, many client-specific interfaces are better than one general-purpose interface
Similar to the Single Responsibility Principle, the goal of the Interface Segregation Principle is to minimize the side consequences and repetition by dividing the software into multiple, independent parts.
Next: Check out the Interface Segregation Principle article to know more about this principle (Coming soon..)
D — Dependency Inversion Principle (DIP)
“High-level modules should not depend on low-level modules. Both should depend on abstractions”
&
“Abstractions should not depend on details. Details should depend on abstractions”
The dependency inversion principle focuses on the approach where the higher classes are not dependent on the lower classes instead depends upon the abstractions of the lower classes, Any higher classes should always depend upon the abstraction of the classes rather than the details.
Next: Check out the Dependency Inversion Principle article to know more about this principle (Coming soon..)
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler
Find it a good read?
Recommend this post (by clicking 👏 button) so other people can see it too…
reach me on Twitter Balaji Malliswamy.
