This content originally appeared on DEV Community and was authored by Bruno Noriller
Yeah... so, this time I'll be doing something a little different.
I believe I have a way to explain how SOLID works with LEGO!
And... I'm already preparing for people making a enemy of me because of that.
What is SOLID?
The textbook (AKA Wikipedia) definition is:
Five design principles intended to make software designs more understandable, flexible, and maintainable.
It was promoted by Uncle Bob and the acronym was introduced by Michael Feathers.
And even without using all of the SOLID principles, your code will always be better.
BTW... Do I know everything there is to know about SOLID? Noooo.
But ever since I've started thinking of it as LEGOS, they started making a lot more sense to me, and I hope it will do the same for you.
To understand what I'm talking, I'll be assuming you know what LEGO is, because if you don't... well... I'm sorry for you... (or Welcome to Earth!)
S: The Single-responsibility principle
There should never be more than one reason for a class to change.
Take a look at the cover photo again... why are there so many different pieces?
Because each one... does ONE thing.
Let's say you're making something out of LEGO, if you need a yellow brick, you don't need to cut another, larger piece, you just need the one piece you want.
You need other color? No need to recolor it, just take the appropriate piece.
The pieces itself never change!
O: The Open–closed principle.
Software entities should be open for extension, but closed for modification.
Can you change a LEGO brick?
No you can't.
But what if you need a bigger piece?
You'll either take an already bigger piece or you will "make one" by combining smaller pieces.
Each brick being immutable by itself, how do you do that?
You use the knobs and tubes to connect one to another... you extend them without modifying them!
L: The Liskov substitution principle
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
This one is a little trick with LEGO alone...
But think it this way: what if I 3D Print a piece?
The knobs and tubes in either one don't care if there's a brand (or the right brand), they only care if it fits or not.
I: The Interface segregation principle
Many client-specific interfaces are better than one general-purpose interface.
Again... look at the cover photo.
Would it even be possible to make anything if pieces wanted to be ALL pieces?
You would have one big piece what would be too much on all situations.
Maybe all you wanted is a little brick with one knob, but instead you have a gigantic thing that... just don't fit.
If it won't be using everything... you just use the right piece for the job.
D: The Dependency inversion principle
Depend upon abstractions, [not] concretions.
More than just plastic pieces, you have stuff made out of LEGO that you wouldn't believe!
Electric toys, prosthetic limbs, drones...
And how is that possible? Have you ever seen motors, batteries, circuit boards with knobs and tubes?
No, because you don't need them.
You "hide" them, behind an abstraction that will have the knobs and tubes and that abstraction will connect with the rest.
You don't need special parts that will fit the LEGO, you just need to encapsulate it in a way that you can use that instead.
Little pieces that you aggregate, one by one, multiples by multiples and that makes a bigger and more complex things... LEGO and programming... who knew right?
Cover Photo by Xavi Cabrera on Unsplash
This content originally appeared on DEV Community and was authored by Bruno Noriller
Bruno Noriller | Sciencx (2021-10-24T23:31:09+00:00) Explaining SOLID with LEGO (and probably making enemies in the tech community). Retrieved from https://www.scien.cx/2021/10/24/explaining-solid-with-lego-and-probably-making-enemies-in-the-tech-community/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.