Courses

Design Patterns in Laravel 11

What's Inside This Course

Welcome to the course about Design Patterns. In this first intro section, let me give you an overview:

  • The main problem with (learning) design patterns
  • Their general definition/usage
  • How to think about them in the Laravel context
  • How this course is structured

This will be a pretty long intro lesson, but I want you to understand the "WHY" behind this course and patterns in general, not just the "how." This is very important in order to grasp the rest of the course better.


The Problem I'm Solving with This Course

First, what is a design pattern? Let's look at a random definition from Wikipedia.

"In software engineering, a design pattern describes a relatively small, well-defined aspect (i.e. functionality) of a computer program in terms of how to write the code.

Conceptually, design pattern may be described as more specific than programming paradigm and less specific than algorithm."

Sounds too vague, right?

Let's try another definition from a well-known resource Refactoring.guru:

"Design patterns are typical solutions to commonly occurring problems in software design. They are like pre-made blueprints that you can customize to solve a recurring design problem in your code."

It's a bit better but still quite theoretical.

Maybe a definition of some specific pattern like Builder would help?

Builder is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code.

Ok, these all sound like human-language English words. But I have only one question:

It reminds me of theory lessons in university: you kind of understand the overall topic but forget the lessons almost immediately. You can't remember what you don't practice.

So, I feel I have three missions with this course:

1. Filter: I won't write about all dozens of possible patterns, only the ones I've seen used in Laravel

2. Translation: I will try to translate the definitions above and explain them in human language

3. Practice: I want to show real examples of patterns both inside Laravel core in /vendor and also in the /app folder of Laravel applications


Warning: This Course is Opinionated

Kind of a small "notice": the topic of design patterns is extremely opinionated.

You can find a lot of debates between developers arguing about patterns naming/usage/semantics while talking about almost the same things. Even in online tutorials, the same design patterns may be discussed/explained differently, depending on the language/framework/author/year.

This is one of the reasons why understanding this topic is so hard. There are usually a few different explanations/opinions for almost any subject about design patterns.

So, take this course as "one of the opinions", as my personal interpretation, based on the Laravel examples I've written/seen. I'm happy to discuss things in the comments and improve the course based on your feedback.


Structure of This Course: Two Big Parts

While preparing for the course, I realized there are two "angles" to look at design patterns.

Angle 1: User. How to recognize the already-built patterns and use them in your apps?

In most practical cases, our job is to recognize and use patterns provided/promoted by the language/framework, like Laravel. So, the first part of the course will be about exactly that: how we write our /app folder code using the patterns.

You also may notice that you're using patterns quite a lot already, just not recognizing that they have specific names.

Angle 2: Creator. How to write code with patterns for others to use? This is a "higher" level for those who create architectural solutions, such as more complex projects or even frameworks.

So, the second part of the course will be about analyzing the /vendor folder of Laravel, discussing the patterns inside so that you can create similar structures in your apps.


Now that you know what to expect inside, let's dive in!

No comments or questions yet...