We cannot discuss design patterns in Laravel without examining a "general" overview outside of Laravel, PHP, or any language.
One of the definitions of a pattern is a "common solution to a common occuring problem". It's a concept: the goal is to leverage an existing concept rather than re-inventing it.
This topic concerns more than just structuring the classes into folders and namespaces. It's not about just Services vs Actions vs Jobs. It's a more profound concept, mostly about creating class objects and interacting between them in a reusable way.
Design patterns may look like overkill in many smaller projects. At first glance, who needs those Singletons, Adapters and Facades, really?
But the practical purpose is this:
Specific example:
This is when you need patterns. To add more features that would follow the same pattern.
Without patterns, those new features may introduce a HUGE MESS in the code.
Those patterns may or may not have the fancy names of Singleton/Adapter/Facade/whatever.
Whatever you call them (if anything), the goal is for the pattern to be RECOGNIZABLE by other developers.
Historically, Laravel has been created for rapid development. So, on the surface, no patterns were strictly emphasized or even needed, except the MVC.
Also, Laravel allows "freedom of speech" in our code and doesn't force many restrictions. There are usually multiple ways to achieve the same thing, which is both a blessing and a curse. So, again, no strict standards mean no well-defined patterns?
As mentioned above, patterns are mainly about OOP and classes/interfaces with some repeating logic.
But in Laravel, the framework itself already abstracts almost all interactions with interfaces/OOP for us.
Question: How often do you need to manually create new Abc() classes in Laravel?
You mostly need just to USE them, right?
User::where()->get();
store(Request $request)
return redirect()->route();
And if you need separate classes/drivers like sending Slack/Email, you can configure them:
.env or config/xxxx.php valuestoEmail, toSms, toWhatever
As a result, developers mostly don't need to create class objects proactively.
And even more rarely do they have to think about any design patterns. Cause almost all patterns are already inside the framework, devs just need to use them.
Also, patterns are about the rules with interfaces. So, when was the last time you needed to create an interface with Laravel?
On the opposite side, there are many "pragmatic" devs who are familiar with patterns in general or know them from other languages/frameworks and then try to find/adapt them in Laravel. And quite often, it feels like a mismatch.
Of course not. The reality is that Laravel has its own patterns or its different versions of implementation of well-known global patterns.
So, we need to talk about patterns in Laravel specifically, with examples.
This is exactly what our next course section is about. So, enough with the theoretical intro, let's (finally) dive into the code, looking at the patterns.