My last post about SOLID Design: The Single Responsibility Principle (SRP) generated some discussion on reddit. The discussion originated from a remark considering SOLID principles as a Cargo Cult. Taking account the definition of Cargo Cult the metaphor is a bit provocative but it is not unfounded.
A cargo cult is a belief system among members of a relatively undeveloped society in which adherents practice superstitious rituals hoping to bring modern goods supplied by a more technologically advanced society
The recent Boeing’s 737 Max fiasco revealed that some parts of their software have been outsourced to $9-an-hour engineers. Those engineers shouldn’t be blamed for not achieving top notch software taking account the budget. Nevertheless it is clear that a lot of software written nowadays look like this cargo cult plane. For many real-world developers, SOLID principles are superstitious rituals whose primary goal is to succeed during job interview.
The SRP article underlines that SRP is the only SOLID principle not related to the usage of abstraction and polymorphism. SRP is about logic partitioning into code: which logic should be declared in which class. But SRP is so vague it is practically useless from its two definitions.
Definition 1: A class should have a single responsibility and this responsibility should be entirely encapsulated by the class.
Definition 2: A class should have one reason to change.
One can justify any class design choice by tweaking somehow what is a responsibility or what is a reason to change. In other words, as someone wrote in comment: Most people who “practice” it don’t actually know what it means and use it as an excuse to do whatever the hell they were going to do anyways.
We can feel bitterness in those comments, certainly coming from seasoned developers whose job is to fix mistakes of $9 an hour engineers.
SOLID Principles vs. OOP Patterns
We must remember that SOLID principles emerged in the 80s and 90s from the work of world-class OOP experts like Robert C. Martin (Uncle Bob) and Bertrand Meyer. Software writing is often considered as an art. Terminologies such as clean code or beautiful code have been widely used. But art is a subjective activity. In this context, SOLID principles necessarily remain vague and subject to interpretation. And this is what makes the difference between a SOLID principle and an OOP pattern:
- A SOLID Principle is subjective. It helps to guide the usage of powerful concepts of Object Oriented Programming (OOP).
- An OOP Pattern is objective. It is a set of recipes to implement a well identified situation with the OOP concepts.
Despite a restraint number of keywords and operators, the OOP toolbelt of languages such as C# or Java is very rich. With a few dozens of characters it is possible to write code that puzzle experts. C# especially gets richer and richer with many syntactic sugars to express complex situations with just a few characters. This power is a double edged sword: seasoned developers can write neat and compact code. But on the other hand it is easy to misuse this power, especially for junior developers and all those that write code just to pay their bills.
Always keep in mind the KISS principle
Someone wrote in comments: “SOLID encourages abstraction, and abstraction increases complexity. It’s not always worth it, but it’s always presented as the non-plus ultra of good approaches.”
The only reason to be for abstraction in OOP is to simplify the implementation of a complex business rule.
- Abstracting Circle, Rectangle and Triangle with an IShape interface will dramatically simplify the implementation of a shape drawing software.
- On the other hand, creating an interface for each class is a waste of resource: not every concepts in your program deserve an abstraction.
This is why the Keep It Simple Stupid KISS principle should be always kept in mind: don’t add up extra implementation complexity on top of the business complexity.
SOLID and Static Analysis
I have been in the .NET static analysis industry since 2004. At that time I was consulting for large companies with massive legacy apps that were very costly to maintain. Books like Robert Martin’s Agile Principles, Patterns, and Practices made me realize that the source code is data. This data can be measured with code metrics. And the same way relational data can be crawled with SQL queries, code as data can be crawled with code queries. For example:
|
1 2 3 |
from m in Application.Methods where m.CyclomatiComplexity > 15 && m.PercentageCoverage < 100 select new { m, m.CyclomatiComplexity, m.PercentageCoverage } |
This query will objectively match complex methods not fully covered by tests. There are situations where one can argue that static analysis returns false positives but there is no justification for complex methods not well tested.
Not all aspects of SOLID principles can be objectively measured and verified. However static analysis can help bring objectiveness. For example:
- A class with many methods and fields and with a poor Lack of Cohesion Of Method (LCOM) score certainly has too many responsibilities.
- A base class that uses some of its derivative is objectively a violation of the Open Close Principle (OCP).
- A method that overrides a base method and that throws NotImplementedException or NotSupportedException is objectively a violation of the Liskov Substitution Principle.
- An interface presenting a dozen of method is objectively a violation of the Interface Segregation Principle (ISP).
- Some code metric exists to measure both coupling over implementations and over abstractions. Those metrics can help pinpoint violations of the Dependency Inversion Principle (DIP).
SOLID and Testability
Regularly applying such rules will avoid taking SOLID too far to the point it becomes detrimental. However there are still all those aspects of SOLID, and code design in general, that must be left to creativity and interpretation. Experience in software development helps a lot here: over the years one refines his/her gut feeling about which design will increase flexibility and maintainability.
By definition juniors developer have no experience. However anyone can relentlessly struggle for 100% code coverage by tests. Being able to fully cover your code means, by definition, that your code is testable. Testability doesn’t come by chance. The properties that leads to full testability are the same properties that leads to high maintainability. Those properties include:
- Easiness to use API
- Domain classes well isolated
- Careful map of logic to classes
- Short classes and short methods
- Cohesive classes
- Abstractions and polymorphism used judiciously
- Careful management of states mutability
Advice to add up objectivity when applying SOLID principles
Not everyone is a senior developer with a passion for well designed code. As a consequence Cargo Cult usage of SOLID principles is common. To improve the design some objectivity needs to be added in the development process. Here are my 3 advices for that:
- KISS principle first, always struggle for simplicity: if it is complicated it is not SOLID.
- Use static analysis to automatically monitor some measurable aspects of SOLID. Gross violations of code quality rules and metrics are also SOLID principles violations.
- Refactor your code until it becomes seamlessly 100% coverable by tests. Code that cannot be easily 100% covered by tests is not SOLID.
SOLID is a model for Object Oriented Software Engineering, like all models it is an abstraction and has limitations.
It provides useful rubrics for organizing our thinking about what we’re doing, but when the rubber hits the road in the real world the facts on the ground always take precedence over any ivory tower theoretical construct.
Applying a model outside its limits is committing what I call the “mapping fallacy”. The model is not the thing modeled, the map is not the territory.
I love your reminder that code is data. I learned this through SICP, so I guess I should (eventually) read Robert Martin’s Agile Principles, Patterns, and Practices.
Concerning coverable code, my shortcut is just to use TDD, it forces you to have covered code and is of great help to write well-designed code. Concerning Cargo-Cult, I can only agree. Most of the industry-best practices are actually the result of some expert’s experience. This is not to say that they are wrong, but that they are lacking context and that we need some experience ourselves to understand them. Last year I had a data science intern to work on predicting test failures given a commit. A very interesting side-result was that test failures were correlated with commits that were large, in code that was non-modular or that did not follow the open-close principle! To me, this means that these principles are definitely not Cargo-Cult! I’m currently writing on some blog posts to explain the full story.
Thanks for your post