Patterns: In General VS In Laravel

We cannot discuss design patterns in Laravel without examining a "general" overview outside of Laravel, PHP, or any language.

The General Definition/Purpose of Patterns

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:

1. You build a function that may be implemented in two different ways
2. Then a new developer comes to the team, and their task is to add a new THIRD way
3. Question: Have you built the first two ways in a PATTERN, so that the newcomer would recognize it and accomplish the task correctly/easily?

Specific example:

1. You're working on an e-shop project with delivery services like UPS and FedEx, using their APIs.
2. A new developer comes with the task of adding a DPD delivery partner.
3. Would it be easy/possible to do without breaking anything in existing UPS/FedEx functionality?

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.

Patterns: The Problem with "Laravel Way"

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();
• etc.

And if you need separate classes/drivers like sending Slack/Email, you can configure them:

• .env or config/xxxx.php values
• Type-hinting which class to use
• Notification toEmail, 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.

So, Laravel is "Anti-Pattern"?

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.