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.
ISP – Interface Segregation Principle
When they throw in everything but the kitchen sink…
In researching for this blog segment, I fell into a black hole of principles that all said the same thing in varying degrees: It is dangerous to depend on more than you have to.
The fact of the matter is, some things we have control over – and some things we don’t. We have control over what we architect ourselves.
In a non-software example, if I was designing a pizza shop, I would segment the different phases of the pizza making process. Chopping vegetables should not interfere with raising and kneading the dough. Baking the pizza shouldn’t interfere with the other stations either. Of course, for this example we all know that each process is fundamental to the final outcome – but each phase is independent.
Op1 – Vegetable wash and prep.
Op2 – Prepare dough
Op3 – Combine and bake
These operations are commonly used together, so I can combine them into a class. However, each worker may rely on different stations. We can think of each station as an interface.
Halfway through our day, something unexpected happens and our oven breaks. We’re able to get a replacement, but it’ll take hours. What’ll happen to our process? Since each of our stations are independent, the vegetable choppers don’t need to stop working. Neither do the dough preppers. Work can still be done while the oven is down. It’s still not ideal but it’s not catastrophic. Imagine if we had to wait for a new oven to chop vegetables or prepare the dough…if you’ve ever made your own dough you know it can take hours…
Even if the oven just needs a scheduled cleaning – the other stations do not care.
Frameworks, on the other hand, are not necessarily in our control. They’re large with dependencies our software may not care about. Like linking your arms with a stranger and accepting all of their drama without any emotional investment on your part. It’s important to only include the parts that are necessary.
Interested in the black hole I was talking about earlier? Check out Clean Architecture: A Craftsman’s Guide To Software Structure and Design.
Next time, we’ll finish off the SOLID! Series with The Dependency Inversion Principle. Until then, happy clean coding!