So S.O.L.I.D development seems to be the new buzz word at the moment. Now even though we all know that code that is loosely-coupled and highly cohesive leads to greater maintainability and testability, sometimes it is difficult to tangibly measure the benefits that well structured code can actually bring to the business.
A code base that follows the S.O.L.I.D principles will typically have the following characteristics:
- A larger number of classes relative to the lines of code
- Smaller classes
- Smaller methods
Now when I contrast this with the very typical, legacy code base that I am currently working with things are very different.
- Far fewer classes relative to the total number of lines of code
- Large (God) classes
- Large methods
Where I’m working currently we have a large team working on a number of concurrent projects all working in the same code base. Because of the way our code is structured we typically have a lot of problems merging our code because there are many classes that have to much responsibility, do too much and know about too many other classes. This means that the same classes time after time are modified for different projects. This in turn causes us far more merge conflicts when trying to reintegrate our code. Now problems merging code means longer project timelines and increased costs to the customer.
When S.O.L.I.D principles are adhered to the way we write code is far different. To add functionality to our system we normally try to achieve this by adding new code and classes rather than modifying existing code (Open Closed Principle – where our system is open for extension but closed for modification). Typically because our classes do less and are smaller the chances of two projects working on the exact same class is also reduced, thus reducing the chances of merge conflicts.
S.O.L.I.D and good OO design principles in your code are not just wooly concepts banded around by academic types but are good sound principles that can save your organization time and money in the long run.