Solid PHP – The first 5 SOLID principles in PHP 2022

Is it incorrect? No, in my opinion, knowing the theory is less crucial than developing clean and straightforward code. But don't dismiss the notion entirely. How else will you pass on your knowledge? How do you defend your code during a code review discussion? You must be grounded in theory and universally recognised norms.

But it's also useful to understand the fundamentals of what clean and straightforward code looks like. The SOLID principles are applicable to any object-oriented programming language. Because I work with Symfony on a regular basis, I'll demonstrate several PHP fundamentals.

So, let us go through the 5 SOLID concepts together.

Single responsibility principle (SPR):

This, I believe, is the most well-known rule (probably because it is the first and some people did not read on). But, truly, I believe it is critical. A class should have one, and only one, cause to change," Uncle Bob says. What does it imply? This phrase is not useful to me. According to other interpretations, a class or a function should only accomplish one thing.

But what exactly is it? Is user registration a separate thing? Or maybe it's more, because registrations contain some other minor tasks, such as password encryption, storing to a database, and sending an e-mail.

Is it one thing to send an email? After all, it entails several procedures, such as drafting the e-mail content and topic, obtaining the user's e-mail address, and dealing with the answer. Should we create a new class for each of these activities? How far should we take this "single responsibility"?

Open/closed principle (OCP):

Second, based on SOLID principles. "Code should be available for expansion but closed for alteration," according to the general explanation. What this implies in reality is unclear to me. Perhaps the effect of not following this rule explains it better. Changing a method's declaration may cause it to fail everywhere it is utilised. The essential point is that the modifications must be backward compatible. Of course, it's preferable to build code that works flawlessly from the start and never has to be changed, but we don't live in a perfect world.

Liskov substitution principle (LSP):

The substitution principle is true for well-designed class inheritance. Barbara Liskov is the creator of this principle. According to the idea, we can substitute any inheriting class for the base class. We must be able to utilise a subclass instead of the main class if we implement one. Otherwise, it shows that inheritance was wrongly implemented.

Interface segregation principle (ISP):

When he worked at Xerox, he established this idea. They couldn't keep up with the never-ending process of integrating code updates. "No client should be compelled to rely on techniques that it does not employ," the regulation states. The interface user should not be compelled to rely on approaches he is unfamiliar with. We should not employ "fat interfaces," which declare several methods that might be left unused. It is preferable to have a few focused little interfaces rather than one that is excessively generic. It also adheres to the notion of sole responsibility.

Dependency inversion principle (DIP):

This rule is the last of the SOLID principles:

• Nothing should be imported from low-level modules by high-level modules. Both should be predicated on abstractions (e.g., interfaces).
• Abstractions should not be based on specifics. Specifics (concrete implementations) should be based on abstractions.

What does it imply? We should limit our reliance on individual implementations and instead focus on interfaces. If we alter the interface (it violates the open/close principle), we must also change the implementations of this interface. However, unless we need to update a specific implementation, we are unlikely to need to change our interface.

Visit Us:?corp.infogen-labs.com?

Social Media:?Instagram?|?Facebook?|?LinkedIn?|?YouTube?|?Twitter