In computer programming, the term SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable (thanks Wikipedia) – but what does that actually mean?
There you have it, follow these principles and you’ve begun your path to clean design.
In this series, we’re going to try to really understand each one of the principles.
Open for Extension – Closed for Modification
Suppose we designed power drills like we designed software (ahem, poorly architected software)…
Each drill would be designed with a single end goal in mind:
- “I want to make a 1/4 inch hole.”
- “I want to be able to turn a #6 screw faster.”
- “I want to make a hole that I can turn a #10 screw into.”
Each piece of equipment would be contructed specifically for that end goal. Changing that end goal would mean either:
- Making a new, different drill for each purpose.
- Ripping out the inner components and connectors to adjust for the new end goal.
Thankfully, we do not design drills that way. Each drill is constructed with a modular mindset. The core essential stays the same, carefully seperated from the aspects that might change (i.e. bit size and type).
This works magnificently – why not design software that way? Our core would be what definitely does not change, and we engineer interfaces (n.) that can accept the pieces that MAY change. It takes practice to recognize the components we need to seperate. ‘Closed for modification’ doesn’t mean we get it right in the first attempt either – but we always need to keep the modular mindset.
So how does this relate to code?
Robert C. Martin uses a nifty example in Clean Architecture: a Craftsman’s Guide to Software Structure and Design.
Say we have a fictional bank, Summit Financial, who was born in the digital age and believes in minimal paper waste. Summit Financial primarily uses a web app to fetch and display their data. It is scrollable and displays negative numbers in red. An old-school CEO steps to the plate and likes the smell and feel of paper in his hands when he holds meetings.
He wants the financial reports to be printed in black and white, and paginated. The appropriate page headers, page footers and column labels should be included. Negative numbers are to be surrounded by parentheses.
This can be a nightmare without the proper architecture. Ideally no legacy code should be touched. Remember the drill example – the parts that may change should be swappable. In Summit Financial’s case, the financial data remains the same and the display changes.
Martin goes into great detail about component seperation, but the simplified version is this:
FINANCIAL DATA —-> FINANCIAL ANALYZER —-> FINANCIAL REPORT DATA
For our simplified purpose, this is the main body of the drill.
The report is using two “bits”:
FINANCIAL REPORT DATA
WEB REPORTER PRINT REPORTER
Change the need; change the bit. Architected this way, the developers have no need to touch prior code (and risk breakage trying to adjust it for either scenario). We can extend the capabilities without modifying the original code!
If Summit Financial wanted to view their data in VR, with 3D blocks and mazes like 1993 tech whizzes…we don’t have to touch the financial report data, web reporter, or print reporter.
I took a few more liberties than Bob Martin’s original explaination, but you get the gist.
Next time, we’ll explore the Liskov Substitution Principle – until then, happy clean coding!