We earn commission when you buy through affiliate links.
This does not influence our reviews or recommendations.Learn more.
Writing computer programs is great fun.
Unless you have to work with other peoples code.
So, why are the codebases so complex that we feel like gutting ourselves?
The end result: a soupy mess that very few want to touch and nobody understands.
Welcome to the first day of the job!
But it doesnt have to be this way.
Writing good code, code that is modular and easy to maintain, isnt that hard.
These guiding principles are represented by the acronymSOLID.
Perhaps youve heard of the term SOLID principles before, perhaps not.
I was like, What??!
Anyway, enough of it.
Its time for something serious: if youre like me, youre probably wondering, Okay, all good.
But why the heck should I care?
And thats the spirit we need to maintain if we want totrulylearn things.
So, why does all this song and dance about Single Responsibility matter at all?
Lets see an example before I explain my interpretation.
And its easy to see what it does: register new users.
It looks fine and works fine, but theres a problem its not future-proof.
And by future-proof, I mean that its not ready to handle change without creating a mess.
What do you do?
Create a similar route in theapi.phpfile and write a JSON-driven controller function for it?
Fine, and then what?
Copy all the code from this function, make a few changes, and call it a day?
This is indeed what many developers are doing, but theyre setting themselves up for failure.
What about a client who has a legacy system running on the XML format?
And then theres another one for SOAP.
And God knows what else will come the next day.
Sure there are ten files, youd argue, but its all working fine so, why complain?
But then comes the gut-punch, the nemesis of software development change.
Suppose now, that your client/employers needs have changed.
Even a singleerrorcan cause major business loss.
How did we reach this hell?
Its doing too many things!
Look at the code now: much more compact, easy to understand .
and most importantly, adaptive to change.
Well, that was quite a tour!
And weve covered just one of the five principles.
The world changes, business changes, and thus, code changes no getting around that.
So, back to the million-dollar question: how do you write code that survives change?
And here, Im afraid, nobody has a clear answer.
With that in mind, lets look at one such technique.
Suppose we need to add the functionality to convert a given HTML content (maybe an invoice?)
into a PDF file and also force an immediate download in the web client.
But theres a slight problem.
Our controller method is too dependent on the MilkyWay class.
If the next version of the MilkyWay API changes the interface, our method will stop working.
And why is that bad?
All this waste because we created a method that was not closed to change.
Can we do better?
Yes, we can!
Yeah, I know, its another of those OOPSisms that make no sense the first time.
But what its saying is that our code should depend ontypesof things, and not particular things themselves.
Now, what tools do we have in PHP for creating new types?
Broadly speaking, we have Inheritance and Interfaces.
As a result, all those classes will be considered to be of typeIPDFGenerator.
So, how is all this connected to the Open-Closed Principle and Laravel?
This something that I mentioned takes the form of theService Containerin the Laravel world.
For now, just think of it as something that can create new class instances for us.
Lets see how this helps.
First off, we are receiving our PDF generator class instance in the function argument.
This is being created and passed to us by the Service Container, as e discussed earlier.
The code is also cleaner and theres no mention of API keys, etc.
But, most importantly, theres no trace of theMilkyWayclass.
WTF is thisMilkyWay??
and constantly worry about it at the back of their head).
But the biggest benefit of all?
This method is now closed for modification and change-resistant.
Allow me to explain.
L is for Liskov Substitution
Liskov-what??
This thing sounds like something straight out of an Organic Chemistry textbook.
But hold your horses for a second!
Trust me, this principle is as easy to understand as it is intimidating in its name.
In fact, it might just be the easiest principle of the five to understand (well, err .
if not the easiest, then at least it will have the shortest, most straightforward explanation).
Keep on working, of course!
So, whats the big deal about this principle?
That wasnt so bad now, was it?
I is for Interface Segregation
Interface Segregation .
hmm, that doesnt sound so bad, does it?
Sounds like its something to do with segregating .
I just wonder where and how.
If you were thinking along these lines, trust me, youre almost done understanding and using this principle.
Lets look at a very common and practical example.
Does that mean its all the fault of the Repository pattern?
No, not at all!
The solution is simple, and is also the name of the principle were discussing: Interface Segregation.
The point is, we shouldnt create our interfaces blindly.
And we also shouldnt make assumptions, no matter how experienced or smart we think we are.
(Side note: Special cases might still arise, and that is fine because no design is perfect.
As long as you write software for a living, remember that its the ideal everyone is striving for.
Yes, makes sense.
We already saw a great example of it in the earlier part of this article.
The tables have turned, and thats why we call this aninversionof dependencies.
Guess what, thats it!
when none of us is going to be authoring libraries.
