If you have been working with object oriented programming (OOP) for some time you have probably heard of the SOLID principles. There is a lot of information available online on SOLID, of various quality. In this blog series, where you are currently reading the first part, I will cover the principles in detail and explain them in a way that hopefully makes sense to most developers.
Benefits
The first question we should answer is the why. Why should you put time and effort into learning about SOLID?
To answer this question we must first recognize that code that is worked on without any clear structure or rules will grow into an unmaintainable nightmare over time, it will rot. Adding or changing features becomes harder and harder and requires an increasing amount of time and effort. Finally a decision is usually made to start over and re-write large portions of the application. Then the whole process starts over.
More detailed, the symptoms of poor design are:
- Rigidity – It is difficult to make changes to the source code
- Fragility – It is easy to break the application when making changes
- Immobility – It is hard to re-use portions of the code
- Viscosity – It is easier to make ”hacky” changes than following the intended design
- Needless complexity – The code is littered with unnecessary constructs that makes the code complex and difficult to understand
- Needless repetitions – The code contains a lot of code blocks that are just copy/paste, maybe with some smaller modifications
- Opacity – The code is difficult to understand
If you can accept that, with changing requirements and changes to the code to address these changes, over time the code will start to show one or more of the symptoms listed above. Then you can also accept that some sort of strategy or set of rules needs to be applied to address these symptoms. This is where SOLID comes in. The goal of the SOLID principles is to make your code easier to develop, understand, maintain, and expand. And to keep it that way in the long run. Sounds like a nice goal doesn’t it?
Taking action
It is important to understand that principles are applied in order to solve symptoms of poor design. They are not applied all over the system just because someone told us it would be a good thing to do. Over-conformance to the principles leads to needless complexity. Understand why you do things a certain way and when it is a good time to do it!
When introducing new functionality or making changes to existing code a good approach is to try to introduce the simplest thing that could possibly work. Avoid trying to think ahead too much and adding complexity in an attempt to future proof the code for requirement changes that might come sometime in the future.
Then, when you realize that you do have, or are about to introduce, a code smell, then it is the time to take action. Do not let code smells accumulate and believe you can fix them later. When you have identified a smell, take action immediately.
- Identify the problem
- Diagnose the problem by applying design principles
- Solve the problem by applying an appropriate design pattern
Brief history
The theory of the SOLID principles were introduced by Robert C. Martin in his 2000 paper Design Principles and Design Patterns but the acronym was introduced by Michael Feathers later. Martin did however not come up with all the principles himself but rather collected them and introduced them as a set of principles that has great benefits when combined.
The five different principles that makes up SOLID are:
- Single Responsibility Principle (SRP)
- Open Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
Conclusion
Code that is being developed without certain principles and strategies will start to rot, introducing code smells that will grow bigger and more severe over time. The SOLID principles helps diagnosing these code smells and adhering to them will help to keep the code in a maintainable state over time.
Next post will be on the first principle of SOLID, the Single Responsibility Principle, SRP.