Software design patterns help developers to solve common recurring problems with code. Let's explore 10 patterns from the famous Gang of Four book and implement them with JavaScript and TypeScript https://fireship.io/lessons/typescript-design-patterns

#programming #compsci #learntocode

🔗 Resources

Learn more from Refactoring Guru https://refactoring.guru/design-patterns/
GOF Design Patterns Book https://en.wikipedia.org/wiki/Design_Patterns
Criticism of Design Patterns https://blog.codinghorror.com/rethinking-design-patterns/

📚 Chapters

00:00 Design Patterns
01:00 What are Software Design Patterns?
01:34 Singleton
02:24 Prototype
03:46 Builder
04:23 Factory
04:54 Facade
05:47 Proxy
06:45 Iterator
07:47 Observer
08:58 Mediator
09:50 State


🔥 Get More Content - Upgrade to PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- TypeScript and JavaScript Design Patterns
- Algorithm vs Design Pattern
- What is Gang of four?
- Are design patterns still relevant?
- Design patterns basics tutorial
2024-02-04T05:31:32.176Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
2c2d95bf-9d99-4402-8e0b-47617922570b
3b25816141cb43fb8f76b972cf3f5b6133bf905100b0dbedc4097c626d0587d2
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
When you first become a junior developer, your code will look like Play Doh snakes.
But as you progress to senior developer and learn about software design patterns, your code will look like the Sistine Chapel.
But when you then progress to principal engineer, you'll realize that nobody wants to maintain the Sistine Chapel for a silly website and go back to in Play Doh snakes.
In today's video, you'll learn about 10 different software design patterns along with the pros and cons of using them, which can be very subjective and controversial.
Scholl.
One of the most influential books in the history of programming is Design Patterns by 4 c plus plus engineers called the Gang of 4.
It breaks down 23 different approaches to address recurring problems that programmers face, which are categorized as creational patterns, how objects are created, structural patterns, how objects relate to each other, And behavioral patterns, how objects communicate with each other.
Becoming a proficient software engineer is not about memorizing the syntax of a programming language, but rather the to solve problems with it.
By the end of this video, you'll understand a variety of different patterns for solving problems as they relate to modern app developers.
Before we get started, I wanna give a big shout out to refactoring.guru.
They gave me permission to use some of their graphics that explain design patterns better than anything else out there.
They're based in Ukraine and it's seriously one of the coolest programming websites on the Internet.
Design patterns are really interesting because they're not This like algorithms that you can copy and paste from Stack Overflow.
You actually need to use your brain to implement them.
It can be tempting to implement them all over the place, but when used improperly, They can add additional complexity and boiler plate to a code base.
The book is not the bible, and there are many criticisms of it.
Regardless, knowing how To recognize design patterns, we'll help you level up as a programmer.
The first pattern we'll look at is singleton, which is very easy to understand.
It's a type of object that can only the instantiated ones.
In TypeScript, we might implement a singleton class called settings to represent the global app settings data.
We'll give it a static instance property and then make its constructor private so that it cannot be instantiated with a new keyword.
We then create a static get instance method that will check to see If the instance has already been created, and if not, it will create a new one.
And that ensures that only one object can be created.
That's great and all, but here's where things become a little more nuanced.
In JavaScript, we have object literals and also the concept of global data, and objects are passed around by reference.
We get all the same basic characteristics as this pattern by simply creating a global object.
The pattern itself is really just extra boilerplate that we don't need.
It's an entirely different story in c plus plus but the moral is to lean on your language's built in before implementing a fancy design pattern.
Now let's take a look at the prototype pattern, which is just a fancy word for clone.
If you've done object Minted programming, you should be familiar with inheritance, where a class can be extended with a subclass.
One problem with inheritance is that it can lead to a complex hierarchy of code.
The prototype pattern is an alternative way to implement inheritance, but instead of inheriting functionality from a class, it comes from an object that's already been created.
This creates a flat prototype chain that makes it much easier to share functionality between objects, especially in a dynamic language like JavaScript, which supports prototypal inheritance out of the box.
Imagine we have an object named zombie.
This is our prototype, but now we want to create a new object based on it that also has a name.
We can do that with object create by passing the zombie as the prototype, then specify additional properties like name for the new object.
The interesting thing is that if you log this object, you'll only see the name and not the eat brains method.
However, if you try to call that method it will the work.
That's because JavaScript will go up the prototype chain until it reaches the root looking for any methods or properties on the parent objects.
You can always get the prototype from an object by using this proto property.
However, that's not a modern best practice, and instead you should use object get prototype of.
Now, when it comes to classes in JavaScript, prototype refers to its constructor.
And that means that we can extend a class with additional functions if we want to.
However, that's also generally considered a bad practice.
Now, let's switch gears to the builder pattern.
Imagine you're running a hotdog stand, and when a customer places an order, they need to tell you everything they want in the sandwich in the constructor.
That works, but it's kind of hard To keep track of all these options, and we might want to defer each step to a later point.
With the builder pattern, we create the object step by step using methods rather than the constructor, and we could even delegate the building logic to an entirely different class.
In JavaScript, we'll have each method return this, which is a reference to the object instance.
That allows us to implement method chaining where we instantiate an object, then chain methods to it, but always get the object as the return value.
You'll come across this pattern frequently with libraries jQuery, but it's gone a bit out of style in recent years.
Another pattern you may come across is factory.
Instead of using the new keyword to instantiate An object, you use a function or method to do it for you.
That may sound trivial, but here's a practical example.
Let's imagine we're building a cross platform app that runs on both iOS and Android.
They both have the same interface, but in our code we're doing a bunch of conditional checking to determine which button to show.
That's not very maintainable.
Instead, we can create a sub class or function that will determine which object to instantiate.
Now instead of repeating the same logic, we use the factory to determine which button should new rendered.
Now, we're ready to look at the first structural pattern, facade.
A facade is the face of a building.
Inside that building, there's all kinds of shenanigans, corruption, and complexity that the end user doesn't need to know about.
A facade is basically just a simplified API to hide other low level details in your code base.
Let's Imagine we have classes for the plumbing system and electrical system, and inside of them, we have all kinds of complex stuff going on like pressure and voltage.
The people living in the house don't need access to these low level details.
So we create a facade class that contains the low level systems as dependencies, but then simplifies their operation.
Like, we might Combine all of the electrical and plumbing details into a single method, so the end user can simply turn them on or off with a single method.
Almost every package that you install with JavaScript that could be considered a facade in some way.
Like, jQuery is a great example of a facade for the more annoying low level JavaScript features.
The next structural pattern The look at is proxy, which is just a fancy word for a substitute.
Like in school, you might have a substitute teacher to replace the real thing.
In programming, you can replace a target object with the proxy.
But why would you ever wanna do that?
Well, a great case study is the reactivity system in Vue.
Js.
In Vue, you create data, but the framework itself needs a way to intercept that data and update the UI whenever that data changes.
The way vue handles that is by replacing the original object with a proxy.
A proxy He takes the original object as the first argument, then a handler as the second argument.
Inside of which, we can override methods like get and set, which allows us to run code whenever a property is accessed just on the object were changed.
For example, inside of set, we might tell the framework to rerender, then use reflect to update the data on the original object.
The end user can now work with the proxy just like the original object, but it can trigger these side effects behind the scenes.
Proxies are also commonly used when you have a very large object that would be expensive to duplicating memory.
And now we're ready to look at some behavioral patterns, starting with iterator.
The iterator pattern allows allows you to traverse through a collection of objects.
Modern languages already provide abstractions for the iterator pattern like the for loop.
When you loop over an array of items, You're using the iterator pattern, but one thing that really chops my ass about JavaScript is that there's no built in range function.
What I wish I could do is easily iterate 10 times at a certain interval.
We can actually do that fairly easily by implementing our own iterator pattern.
In JavaScript, you can do that by defining an object that has a next method on it.
That function needs to return an object that has a value, which would be the current value in the loop, and a done property so it knows when to finish iterating.
In this case, we will keep moving on to the next step if the start value is less than the end value.
But for each iteration, We will increment the start value with a step.
Eventually, the start will be greater than the end, at which point we can return an object with the done property as true, and that tells JavaScript to stop iterating.
Now a cool technique here is that we can add symbol iterator to this object, which allows us to use it in a regular or of loop.
At the end of the day, with iteration, you start with a collection and then write some code that determines how to get from the beginning to the end.
It's a pull based system.
Unlike the next pattern we'll look at, observer, which is a push based system.
The observer pattern allows many objects to subscribe to events that but are broadcast by another object.
It's a one to many relationship.
In the real world, you might have a radio tower that sends out a signal, then a bunch of receivers who listen men at the same time.
This pattern is used all over the place in app development, like in Firebase, when your data changes on the server while your client apps are inscribed to it and automatically update it with the latest data.
In our code here, I'm going to bring in the RX JS library to simplify the demonstration of this pattern.
It provides a subject class, which is the data that we want to listen to.
Now once we have a subject, we can add multiple subscriptions to it.
The subject will keep track of all these subscriptions and call their callback functions whenever the data changes.
Experiment with this pattern right now by clicking like and subscribe on this video.
Now at some later point, we can call the next method to push a new value to the subject.
Whenever that happens, every subscription will be notified.
Personally, I like To think of this as a loop that unfolds over the dimension of time, but now let's move on to the mediator pattern.
A mediator is like a middleman or broker.
Imagine we have a class for airplane and runway.
We might have multiple runways and multiple airplanes, and somehow we need to figure out if an airplane is clear to land on a given Runway.
Currently, to do that, all these objects would have to communicate with each other.
We have a many to many relationship that's very dangerous both in real life and in programming.
A solution is to create a mediator, like an air traffic controller, that sits between the runways and the airplanes to provide coordination and communication.
Mission.
Here's a more practical example.
In the Express JS web framework, there is a middleware system.
You have incoming requests and outgoing responses.
Middleware sits in the middle by intercepting Every request, like an airplane, and transforms it into the proper format for the response, the runway.
It provides a separation of concerns and eliminates code duplication.
And that brings us Do our 10th and final design pattern, state, where an object behaves differently based on a finite number of states.
In your code, you've likely They use conditional logic or switch statements to handle a bunch of different possibilities based on the state or data in your application.
Code like this generally doesn't scale very well.
The state pattern allows you to start with 1 base class, then provide it with different functionality based on its internal null state.
The idea is related to finite state machines and libraries like xstate, where the goal is to make an object's behavior predictable based on its underlying state.
In this example, we have a human class that will think something different based on its mood.
Currently, we're doing that with a switch statement, But another way to go about it would be to create a separate class for each possible state.
Inside each class, we will have an identical method that behaves differently.
Now, in the human class, we set the state as a property and whenever that method is called, we delegate it to its current state.
That means whenever the state changes, the object will behave in a completely different way, but at the same time, we don't have to change the API or use a bunch of conditional logic.
I'm gonna keep things simple and wrap it up there, but remember There are a bunch of other design patterns out there to learn.
Become a pro member at FireShip.
Io to learn how to apply patterns like this in real applications.
Thanks for watching, and I will see you in the next one.

Speaker 0: When you first become a junior developer, your code will look like Play Doh snakes. But as you progress to senior developer and learn about software design patterns, your code will look like the Sistine Chapel. But when you then progress to principal engineer, you'll realize that nobody wants to maintain the Sistine Chapel for a silly website and go back to in Play Doh snakes. In today's video, you'll learn about 10 different software design patterns along with the pros and cons of using them, which can be very subjective and controversial. Scholl.

One of the most influential books in the history of programming is Design Patterns by 4 c plus plus engineers called the Gang of 4. It breaks down 23 different approaches to address recurring problems that programmers face, which are categorized as creational patterns, how objects are created, structural patterns, how objects relate to each other, And behavioral patterns, how objects communicate with each other. Becoming a proficient software engineer is not about memorizing the syntax of a programming language, but rather the to solve problems with it. By the end of this video, you'll understand a variety of different patterns for solving problems as they relate to modern app developers. Before we get started, I wanna give a big shout out to refactoring.guru.

They gave me permission to use some of their graphics that explain design patterns better than anything else out there. They're based in Ukraine and it's seriously one of the coolest programming websites on the Internet. Design patterns are really interesting because they're not This like algorithms that you can copy and paste from Stack Overflow. You actually need to use your brain to implement them. It can be tempting to implement them all over the place, but when used improperly, They can add additional complexity and boiler plate to a code base.

The book is not the bible, and there are many criticisms of it. Regardless, knowing how To recognize design patterns, we'll help you level up as a programmer. The first pattern we'll look at is singleton, which is very easy to understand. It's a type of object that can only the instantiated ones. In TypeScript, we might implement a singleton class called settings to represent the global app settings data.

We'll give it a static instance property and then make its constructor private so that it cannot be instantiated with a new keyword. We then create a static get instance method that will check to see If the instance has already been created, and if not, it will create a new one. And that ensures that only one object can be created. That's great and all, but here's where things become a little more nuanced. In JavaScript, we have object literals and also the concept of global data, and objects are passed around by reference.

We get all the same basic characteristics as this pattern by simply creating a global object. The pattern itself is really just extra boilerplate that we don't need. It's an entirely different story in c plus plus but the moral is to lean on your language's built in before implementing a fancy design pattern. Now let's take a look at the prototype pattern, which is just a fancy word for clone. If you've done object Minted programming, you should be familiar with inheritance, where a class can be extended with a subclass.

One problem with inheritance is that it can lead to a complex hierarchy of code. The prototype pattern is an alternative way to implement inheritance, but instead of inheriting functionality from a class, it comes from an object that's already been created. This creates a flat prototype chain that makes it much easier to share functionality between objects, especially in a dynamic language like JavaScript, which supports prototypal inheritance out of the box. Imagine we have an object named zombie. This is our prototype, but now we want to create a new object based on it that also has a name.

We can do that with object create by passing the zombie as the prototype, then specify additional properties like name for the new object. The interesting thing is that if you log this object, you'll only see the name and not the eat brains method. However, if you try to call that method it will the work. That's because JavaScript will go up the prototype chain until it reaches the root looking for any methods or properties on the parent objects. You can always get the prototype from an object by using this proto property.

However, that's not a modern best practice, and instead you should use object get prototype of. Now, when it comes to classes in JavaScript, prototype refers to its constructor. And that means that we can extend a class with additional functions if we want to. However, that's also generally considered a bad practice. Now, let's switch gears to the builder pattern.

Imagine you're running a hotdog stand, and when a customer places an order, they need to tell you everything they want in the sandwich in the constructor. That works, but it's kind of hard To keep track of all these options, and we might want to defer each step to a later point. With the builder pattern, we create the object step by step using methods rather than the constructor, and we could even delegate the building logic to an entirely different class. In JavaScript, we'll have each method return this, which is a reference to the object instance. That allows us to implement method chaining where we instantiate an object, then chain methods to it, but always get the object as the return value.

You'll come across this pattern frequently with libraries jQuery, but it's gone a bit out of style in recent years. Another pattern you may come across is factory. Instead of using the new keyword to instantiate An object, you use a function or method to do it for you. That may sound trivial, but here's a practical example. Let's imagine we're building a cross platform app that runs on both iOS and Android.

They both have the same interface, but in our code we're doing a bunch of conditional checking to determine which button to show. That's not very maintainable. Instead, we can create a sub class or function that will determine which object to instantiate. Now instead of repeating the same logic, we use the factory to determine which button should new rendered. Now, we're ready to look at the first structural pattern, facade.

A facade is the face of a building. Inside that building, there's all kinds of shenanigans, corruption, and complexity that the end user doesn't need to know about. A facade is basically just a simplified API to hide other low level details in your code base. Let's Imagine we have classes for the plumbing system and electrical system, and inside of them, we have all kinds of complex stuff going on like pressure and voltage. The people living in the house don't need access to these low level details.

So we create a facade class that contains the low level systems as dependencies, but then simplifies their operation. Like, we might Combine all of the electrical and plumbing details into a single method, so the end user can simply turn them on or off with a single method. Almost every package that you install with JavaScript that could be considered a facade in some way. Like, jQuery is a great example of a facade for the more annoying low level JavaScript features. The next structural pattern The look at is proxy, which is just a fancy word for a substitute.

Like in school, you might have a substitute teacher to replace the real thing. In programming, you can replace a target object with the proxy. But why would you ever wanna do that? Well, a great case study is the reactivity system in Vue. Js.

In Vue, you create data, but the framework itself needs a way to intercept that data and update the UI whenever that data changes. The way vue handles that is by replacing the original object with a proxy. A proxy He takes the original object as the first argument, then a handler as the second argument. Inside of which, we can override methods like get and set, which allows us to run code whenever a property is accessed just on the object were changed. For example, inside of set, we might tell the framework to rerender, then use reflect to update the data on the original object.

The end user can now work with the proxy just like the original object, but it can trigger these side effects behind the scenes. Proxies are also commonly used when you have a very large object that would be expensive to duplicating memory. And now we're ready to look at some behavioral patterns, starting with iterator. The iterator pattern allows allows you to traverse through a collection of objects. Modern languages already provide abstractions for the iterator pattern like the for loop.

When you loop over an array of items, You're using the iterator pattern, but one thing that really chops my ass about JavaScript is that there's no built in range function. What I wish I could do is easily iterate 10 times at a certain interval. We can actually do that fairly easily by implementing our own iterator pattern. In JavaScript, you can do that by defining an object that has a next method on it. That function needs to return an object that has a value, which would be the current value in the loop, and a done property so it knows when to finish iterating.

In this case, we will keep moving on to the next step if the start value is less than the end value. But for each iteration, We will increment the start value with a step. Eventually, the start will be greater than the end, at which point we can return an object with the done property as true, and that tells JavaScript to stop iterating. Now a cool technique here is that we can add symbol iterator to this object, which allows us to use it in a regular or of loop. At the end of the day, with iteration, you start with a collection and then write some code that determines how to get from the beginning to the end.

It's a pull based system. Unlike the next pattern we'll look at, observer, which is a push based system. The observer pattern allows many objects to subscribe to events that but are broadcast by another object. It's a one to many relationship. In the real world, you might have a radio tower that sends out a signal, then a bunch of receivers who listen men at the same time.

This pattern is used all over the place in app development, like in Firebase, when your data changes on the server while your client apps are inscribed to it and automatically update it with the latest data. In our code here, I'm going to bring in the RX JS library to simplify the demonstration of this pattern. It provides a subject class, which is the data that we want to listen to. Now once we have a subject, we can add multiple subscriptions to it. The subject will keep track of all these subscriptions and call their callback functions whenever the data changes.

Experiment with this pattern right now by clicking like and subscribe on this video. Now at some later point, we can call the next method to push a new value to the subject. Whenever that happens, every subscription will be notified. Personally, I like To think of this as a loop that unfolds over the dimension of time, but now let's move on to the mediator pattern. A mediator is like a middleman or broker.

Imagine we have a class for airplane and runway. We might have multiple runways and multiple airplanes, and somehow we need to figure out if an airplane is clear to land on a given Runway. Currently, to do that, all these objects would have to communicate with each other. We have a many to many relationship that's very dangerous both in real life and in programming. A solution is to create a mediator, like an air traffic controller, that sits between the runways and the airplanes to provide coordination and communication.

Mission. Here's a more practical example. In the Express JS web framework, there is a middleware system. You have incoming requests and outgoing responses. Middleware sits in the middle by intercepting Every request, like an airplane, and transforms it into the proper format for the response, the runway.

It provides a separation of concerns and eliminates code duplication. And that brings us Do our 10th and final design pattern, state, where an object behaves differently based on a finite number of states. In your code, you've likely They use conditional logic or switch statements to handle a bunch of different possibilities based on the state or data in your application. Code like this generally doesn't scale very well. The state pattern allows you to start with 1 base class, then provide it with different functionality based on its internal null state.

The idea is related to finite state machines and libraries like xstate, where the goal is to make an object's behavior predictable based on its underlying state. In this example, we have a human class that will think something different based on its mood. Currently, we're doing that with a switch statement, But another way to go about it would be to create a separate class for each possible state. Inside each class, we will have an identical method that behaves differently. Now, in the human class, we set the state as a property and whenever that method is called, we delegate it to its current state.

That means whenever the state changes, the object will behave in a completely different way, but at the same time, we don't have to change the API or use a bunch of conditional logic. I'm gonna keep things simple and wrap it up there, but remember There are a bunch of other design patterns out there to learn. Become a pro member at FireShip. Io to learn how to apply patterns like this in real applications. Thanks for watching, and I will see you in the next one.
When you first become a junior developer, your code will look like Play Doh snakes. But as you progress to senior developer and learn about software design patterns, your code will look like the Sistine Chapel. But when you then progress to principal engineer, you'll realize that nobody wants to maintain the Sistine Chapel for a silly website and go back to in Play Doh snakes. In today's video, you'll learn about 10 different software design patterns along with the pros and cons of using them, which can be very subjective and controversial. Scholl. One of the most influential books in the history of programming is Design Patterns by 4 c plus plus engineers called the Gang of 4. It breaks down 23 different approaches to address recurring problems that programmers face, which are categorized as creational patterns, how objects are created, structural patterns, how objects relate to each other, And behavioral patterns, how objects communicate with each other. Becoming a proficient software engineer is not about memorizing the syntax of a programming language, but rather the to solve problems with it. By the end of this video, you'll understand a variety of different patterns for solving problems as they relate to modern app developers. Before we get started, I wanna give a big shout out to refactoring.guru. They gave me permission to use some of their graphics that explain design patterns better than anything else out there. They're based in Ukraine and it's seriously one of the coolest programming websites on the Internet. Design patterns are really interesting because they're not This like algorithms that you can copy and paste from Stack Overflow. You actually need to use your brain to implement them. It can be tempting to implement them all over the place, but when used improperly, They can add additional complexity and boiler plate to a code base.
software development
software
graphic design
books
websites
engineering
computer science
programming
The book is not the bible, and there are many criticisms of it. Regardless, knowing how To recognize design patterns, we'll help you level up as a programmer. The first pattern we'll look at is singleton, which is very easy to understand. It's a type of object that can only the instantiated ones.
bible
books
In TypeScript, we might implement a singleton class called settings to represent the global app settings data. We'll give it a static instance property and then make its constructor private so that it cannot be instantiated with a new keyword. We then create a static get instance method that will check to see If the instance has already been created, and if not, it will create a new one. And that ensures that only one object can be created. That's great and all, but here's where things become a little more nuanced. In JavaScript, we have object literals and also the concept of global data, and objects are passed around by reference.
We get all the same basic characteristics as this pattern by simply creating a global object. The pattern itself is really just extra boilerplate that we don't need. It's an entirely different story in c plus plus but the moral is to lean on your language's built in before implementing a fancy design pattern. Now let's take a look at the prototype pattern, which is just a fancy word for clone. If you've done object Minted programming, you should be familiar with inheritance, where a class can be extended with a subclass. One problem with inheritance is that it can lead to a complex hierarchy of code. The prototype pattern is an alternative way to implement inheritance, but instead of inheriting functionality from a class, it comes from an object that's already been created. This creates a flat prototype chain that makes it much easier to share functionality between objects, especially in a dynamic language like JavaScript, which supports prototypal inheritance out of the box. Imagine we have an object named zombie. This is our prototype, but now we want to create a new object based on it that also has a name. We can do that with object create by passing the zombie as the prototype, then specify additional properties like name for the new object. The interesting thing is that if you log this object, you'll only see the name and not the eat brains method. However, if you try to call that method it will the work.
languages
toys
evolution
robotics
logic
patents
That's because JavaScript will go up the prototype chain until it reaches the root looking for any methods or properties on the parent objects. You can always get the prototype from an object by using this proto property. However, that's not a modern best practice, and instead you should use object get prototype of. Now, when it comes to classes in JavaScript, prototype refers to its constructor. And that means that we can extend a class with additional functions if we want to. However, that's also generally considered a bad practice. Now, let's switch gears to the builder pattern. Imagine you're running a hotdog stand, and when a customer places an order, they need to tell you everything they want in the sandwich in the constructor. That works, but it's kind of hard To keep track of all these options, and we might want to defer each step to a later point. With the builder pattern, we create the object step by step using methods rather than the constructor, and we could even delegate the building logic to an entirely different class. In JavaScript, we'll have each method return this, which is a reference to the object instance. That allows us to implement method chaining where we instantiate an object, then chain methods to it, but always get the object as the return value. You'll come across this pattern frequently with libraries jQuery, but it's gone a bit out of style in recent years. Another pattern you may come across is factory. Instead of using the new keyword to instantiate An object, you use a function or method to do it for you. That may sound trivial, but here's a practical example.
Let's imagine we're building a cross platform app that runs on both iOS and Android. They both have the same interface, but in our code we're doing a bunch of conditional checking to determine which button to show. That's not very maintainable. Instead, we can create a sub class or function that will determine which object to instantiate. Now instead of repeating the same logic, we use the factory to determine which button should new rendered. Now, we're ready to look at the first structural pattern, facade. A facade is the face of a building. Inside that building, there's all kinds of shenanigans, corruption, and complexity that the end user doesn't need to know about. A facade is basically just a simplified API to hide other low level details in your code base. Let's Imagine we have classes for the plumbing system and electrical system, and inside of them, we have all kinds of complex stuff going on like pressure and voltage. The people living in the house don't need access to these low level details. So we create a facade class that contains the low level systems as dependencies, but then simplifies their operation. Like, we might Combine all of the electrical and plumbing details into a single method, so the end user can simply turn them on or off with a single method.
architecture
modeling
programming
Almost every package that you install with JavaScript that could be considered a facade in some way. Like, jQuery is a great example of a facade for the more annoying low level JavaScript features. The next structural pattern The look at is proxy, which is just a fancy word for a substitute. Like in school, you might have a substitute teacher to replace the real thing. In programming, you can replace a target object with the proxy. But why would you ever wanna do that? Well, a great case study is the reactivity system in Vue. Js. In Vue, you create data, but the framework itself needs a way to intercept that data and update the UI whenever that data changes. The way vue handles that is by replacing the original object with a proxy. A proxy He takes the original object as the first argument, then a handler as the second argument. Inside of which, we can override methods like get and set, which allows us to run code whenever a property is accessed just on the object were changed. For example, inside of set, we might tell the framework to rerender, then use reflect to update the data on the original object. The end user can now work with the proxy just like the original object, but it can trigger these side effects behind the scenes. Proxies are also commonly used when you have a very large object that would be expensive to duplicating memory. And now we're ready to look at some behavioral patterns, starting with iterator. The iterator pattern allows allows you to traverse through a collection of objects. Modern languages already provide abstractions for the iterator pattern like the for loop. When you loop over an array of items, You're using the iterator pattern, but one thing that really chops my ass about JavaScript is that there's no built in range function. What I wish I could do is easily iterate 10 times at a certain interval. We can actually do that fairly easily by implementing our own iterator pattern. In JavaScript, you can do that by defining an object that has a next method on it. That function needs to return an object that has a value, which would be the current value in the loop, and a done property so it knows when to finish iterating. In this case, we will keep moving on to the next step if the start value is less than the end value. But for each iteration, We will increment the start value with a step. Eventually, the start will be greater than the end, at which point we can return an object with the done property as true, and that tells JavaScript to stop iterating. Now a cool technique here is that we can add symbol iterator to this object, which allows us to use it in a regular or of loop. At the end of the day, with iteration, you start with a collection and then write some code that determines how to get from the beginning to the end.
It's a pull based system. Unlike the next pattern we'll look at, observer, which is a push based system. The observer pattern allows many objects to subscribe to events that but are broadcast by another object. It's a one to many relationship. In the real world, you might have a radio tower that sends out a signal, then a bunch of receivers who listen men at the same time. This pattern is used all over the place in app development, like in Firebase, when your data changes on the server while your client apps are inscribed to it and automatically update it with the latest data.
radio
telecommunications
phones
In our code here, I'm going to bring in the RX JS library to simplify the demonstration of this pattern. It provides a subject class, which is the data that we want to listen to. Now once we have a subject, we can add multiple subscriptions to it. The subject will keep track of all these subscriptions and call their callback functions whenever the data changes. Experiment with this pattern right now by clicking like and subscribe on this video. Now at some later point, we can call the next method to push a new value to the subject. Whenever that happens, every subscription will be notified. Personally, I like To think of this as a loop that unfolds over the dimension of time, but now let's move on to the mediator pattern. A mediator is like a middleman or broker. Imagine we have a class for airplane and runway. We might have multiple runways and multiple airplanes, and somehow we need to figure out if an airplane is clear to land on a given Runway. Currently, to do that, all these objects would have to communicate with each other. We have a many to many relationship that's very dangerous both in real life and in programming. A solution is to create a mediator, like an air traffic controller, that sits between the runways and the airplanes to provide coordination and communication. Mission. Here's a more practical example. In the Express JS web framework, there is a middleware system. You have incoming requests and outgoing responses. Middleware sits in the middle by intercepting Every request, like an airplane, and transforms it into the proper format for the response, the runway. It provides a separation of concerns and eliminates code duplication. And that brings us Do our 10th and final design pattern, state, where an object behaves differently based on a finite number of states. In your code, you've likely They use conditional logic or switch statements to handle a bunch of different possibilities based on the state or data in your application. Code like this generally doesn't scale very well. The state pattern allows you to start with 1 base class, then provide it with different functionality based on its internal null state. The idea is related to finite state machines and libraries like xstate, where the goal is to make an object's behavior predictable based on its underlying state. In this example, we have a human class that will think something different based on its mood. Currently, we're doing that with a switch statement, But another way to go about it would be to create a separate class for each possible state.
media
social media
ideologies
journalism
software
logic
infrastructure
aircraft
systems
aerospace
multimedia
air travel
programming
computer science
transportation
robotics
Inside each class, we will have an identical method that behaves differently. Now, in the human class, we set the state as a property and whenever that method is called, we delegate it to its current state. That means whenever the state changes, the object will behave in a completely different way, but at the same time, we don't have to change the API or use a bunch of conditional logic. I'm gonna keep things simple and wrap it up there, but remember There are a bunch of other design patterns out there to learn.
logic
policy
Become a pro member at FireShip.
Io to learn how to apply patterns like this in real applications. Thanks for watching, and I will see you in the next one.
When you first become a junior developer, your code will look like Play Doh snakes. But as you progress to senior developer and learn about software design patterns, your code will look like the Sistine Chapel. But when you then progress to principal engineer, you'll realize that nobody wants to maintain the Sistine Chapel for a silly website and go back to in Play Doh snakes. In today's video, you'll learn about 10 different software design patterns along with the pros and cons of using them, which can be very subjective and controversial. Scholl. One of the most influential books in the history of programming is Design Patterns by 4 c plus plus engineers called the Gang of 4. It breaks down 23 different approaches to address recurring problems that programmers face, which are categorized as creational patterns, how objects are created, structural patterns, how objects relate to each other, And behavioral patterns, how objects communicate with each other. Becoming a proficient software engineer is not about memorizing the syntax of a programming language, but rather the to solve problems with it. By the end of this video, you'll understand a variety of different patterns for solving problems as they relate to modern app developers. Before we get started, I wanna give a big shout out to refactoring.guru. They gave me permission to use some of their graphics that explain design patterns better than anything else out there. They're based in Ukraine and it's seriously one of the coolest programming websites on the Internet. Design patterns are really interesting because they're not This like algorithms that you can copy and paste from Stack Overflow. You actually need to use your brain to implement them. It can be tempting to implement them all over the place, but when used improperly, They can add additional complexity and boiler plate to a code base. The book is not the bible, and there are many criticisms of it. Regardless, knowing how To recognize design patterns, we'll help you level up as a programmer. The first pattern we'll look at is singleton, which is very easy to understand. It's a type of object that can only the instantiated ones. In TypeScript, we might implement a singleton class called settings to represent the global app settings data. We'll give it a static instance property and then make its constructor private so that it cannot be instantiated with a new keyword. We then create a static get instance method that will check to see If the instance has already been created, and if not, it will create a new one. And that ensures that only one object can be created. That's great and all, but here's where things become a little more nuanced. In JavaScript, we have object literals and also the concept of global data, and objects are passed around by reference. We get all the same basic characteristics as this pattern by simply creating a global object. The pattern itself is really just extra boilerplate that we don't need. It's an entirely different story in c plus plus but the moral is to lean on your language's built in before implementing a fancy design pattern. Now let's take a look at the prototype pattern, which is just a fancy word for clone. If you've done object Minted programming, you should be familiar with inheritance, where a class can be extended with a subclass. One problem with inheritance is that it can lead to a complex hierarchy of code. The prototype pattern is an alternative way to implement inheritance, but instead of inheriting functionality from a class, it comes from an object that's already been created. This creates a flat prototype chain that makes it much easier to share functionality between objects, especially in a dynamic language like JavaScript, which supports prototypal inheritance out of the box. Imagine we have an object named zombie. This is our prototype, but now we want to create a new object based on it that also has a name. We can do that with object create by passing the zombie as the prototype, then specify additional properties like name for the new object. The interesting thing is that if you log this object, you'll only see the name and not the eat brains method. However, if you try to call that method it will the work. That's because JavaScript will go up the prototype chain until it reaches the root looking for any methods or properties on the parent objects. You can always get the prototype from an object by using this proto property. However, that's not a modern best practice, and instead you should use object get prototype of. Now, when it comes to classes in JavaScript, prototype refers to its constructor. And that means that we can extend a class with additional functions if we want to. However, that's also generally considered a bad practice. Now, let's switch gears to the builder pattern. Imagine you're running a hotdog stand, and when a customer places an order, they need to tell you everything they want in the sandwich in the constructor. That works, but it's kind of hard To keep track of all these options, and we might want to defer each step to a later point. With the builder pattern, we create the object step by step using methods rather than the constructor, and we could even delegate the building logic to an entirely different class. In JavaScript, we'll have each method return this, which is a reference to the object instance. That allows us to implement method chaining where we instantiate an object, then chain methods to it, but always get the object as the return value. You'll come across this pattern frequently with libraries jQuery, but it's gone a bit out of style in recent years. Another pattern you may come across is factory. Instead of using the new keyword to instantiate An object, you use a function or method to do it for you. That may sound trivial, but here's a practical example. Let's imagine we're building a cross platform app that runs on both iOS and Android. They both have the same interface, but in our code we're doing a bunch of conditional checking to determine which button to show. That's not very maintainable. Instead, we can create a sub class or function that will determine which object to instantiate. Now instead of repeating the same logic, we use the factory to determine which button should new rendered. Now, we're ready to look at the first structural pattern, facade. A facade is the face of a building. Inside that building, there's all kinds of shenanigans, corruption, and complexity that the end user doesn't need to know about. A facade is basically just a simplified API to hide other low level details in your code base. Let's Imagine we have classes for the plumbing system and electrical system, and inside of them, we have all kinds of complex stuff going on like pressure and voltage. The people living in the house don't need access to these low level details. So we create a facade class that contains the low level systems as dependencies, but then simplifies their operation. Like, we might Combine all of the electrical and plumbing details into a single method, so the end user can simply turn them on or off with a single method. Almost every package that you install with JavaScript that could be considered a facade in some way. Like, jQuery is a great example of a facade for the more annoying low level JavaScript features. The next structural pattern The look at is proxy, which is just a fancy word for a substitute. Like in school, you might have a substitute teacher to replace the real thing. In programming, you can replace a target object with the proxy. But why would you ever wanna do that? Well, a great case study is the reactivity system in Vue. Js. In Vue, you create data, but the framework itself needs a way to intercept that data and update the UI whenever that data changes. The way vue handles that is by replacing the original object with a proxy. A proxy He takes the original object as the first argument, then a handler as the second argument. Inside of which, we can override methods like get and set, which allows us to run code whenever a property is accessed just on the object were changed. For example, inside of set, we might tell the framework to rerender, then use reflect to update the data on the original object. The end user can now work with the proxy just like the original object, but it can trigger these side effects behind the scenes. Proxies are also commonly used when you have a very large object that would be expensive to duplicating memory. And now we're ready to look at some behavioral patterns, starting with iterator. The iterator pattern allows allows you to traverse through a collection of objects. Modern languages already provide abstractions for the iterator pattern like the for loop. When you loop over an array of items, You're using the iterator pattern, but one thing that really chops my ass about JavaScript is that there's no built in range function. What I wish I could do is easily iterate 10 times at a certain interval. We can actually do that fairly easily by implementing our own iterator pattern. In JavaScript, you can do that by defining an object that has a next method on it. That function needs to return an object that has a value, which would be the current value in the loop, and a done property so it knows when to finish iterating. In this case, we will keep moving on to the next step if the start value is less than the end value. But for each iteration, We will increment the start value with a step. Eventually, the start will be greater than the end, at which point we can return an object with the done property as true, and that tells JavaScript to stop iterating. Now a cool technique here is that we can add symbol iterator to this object, which allows us to use it in a regular or of loop. At the end of the day, with iteration, you start with a collection and then write some code that determines how to get from the beginning to the end. It's a pull based system. Unlike the next pattern we'll look at, observer, which is a push based system. The observer pattern allows many objects to subscribe to events that but are broadcast by another object. It's a one to many relationship. In the real world, you might have a radio tower that sends out a signal, then a bunch of receivers who listen men at the same time. This pattern is used all over the place in app development, like in Firebase, when your data changes on the server while your client apps are inscribed to it and automatically update it with the latest data. In our code here, I'm going to bring in the RX JS library to simplify the demonstration of this pattern. It provides a subject class, which is the data that we want to listen to. Now once we have a subject, we can add multiple subscriptions to it. The subject will keep track of all these subscriptions and call their callback functions whenever the data changes. Experiment with this pattern right now by clicking like and subscribe on this video. Now at some later point, we can call the next method to push a new value to the subject. Whenever that happens, every subscription will be notified. Personally, I like To think of this as a loop that unfolds over the dimension of time, but now let's move on to the mediator pattern. A mediator is like a middleman or broker. Imagine we have a class for airplane and runway. We might have multiple runways and multiple airplanes, and somehow we need to figure out if an airplane is clear to land on a given Runway. Currently, to do that, all these objects would have to communicate with each other. We have a many to many relationship that's very dangerous both in real life and in programming. A solution is to create a mediator, like an air traffic controller, that sits between the runways and the airplanes to provide coordination and communication. Mission. Here's a more practical example. In the Express JS web framework, there is a middleware system. You have incoming requests and outgoing responses. Middleware sits in the middle by intercepting Every request, like an airplane, and transforms it into the proper format for the response, the runway. It provides a separation of concerns and eliminates code duplication. And that brings us Do our 10th and final design pattern, state, where an object behaves differently based on a finite number of states. In your code, you've likely They use conditional logic or switch statements to handle a bunch of different possibilities based on the state or data in your application. Code like this generally doesn't scale very well. The state pattern allows you to start with 1 base class, then provide it with different functionality based on its internal null state. The idea is related to finite state machines and libraries like xstate, where the goal is to make an object's behavior predictable based on its underlying state. In this example, we have a human class that will think something different based on its mood. Currently, we're doing that with a switch statement, But another way to go about it would be to create a separate class for each possible state. Inside each class, we will have an identical method that behaves differently. Now, in the human class, we set the state as a property and whenever that method is called, we delegate it to its current state. That means whenever the state changes, the object will behave in a completely different way, but at the same time, we don't have to change the API or use a bunch of conditional logic. I'm gonna keep things simple and wrap it up there, but remember There are a bunch of other design patterns out there to learn. Become a pro member at FireShip. Io to learn how to apply patterns like this in real applications. Thanks for watching, and I will see you in the next one.
When
when
you
you
first
first
become
become
a
a
junior
junior
developer,
developer
your
your
code
code
will
will
look
look
like
like
Play
play
Doh
doh
snakes.
snakes
But
but
as
as
you
you
progress
progress
to
to
senior
senior
developer
developer
and
and
learn
learn
about
about
software
software
design
design
patterns,
patterns
your
your
code
code
will
will
look
look
like
like
the
the
Sistine
sistine
Chapel.
chapel
But
but
when
when
you
you
then
then
progress
progress
to
to
principal
principal
engineer,
engineer
you'll
you'll
realize
realize
that
that
nobody
nobody
wants
wants
to
to
maintain
maintain
the
the
Sistine
sistine
Chapel
chapel
for
for
a
a
silly
silly
website
website
and
and
go
go
back
back
to
to
in
in
Play
play
Doh
doh
snakes.
snakes
In
in
today's
today's
video,
video
you'll
you'll
learn
learn
about
about
10
10
different
different
software
software
design
design
patterns
patterns
along
along
with
with
the
the
pros
pros
and
and
cons
cons
of
of
using
using
them,
them
which
which
can
can
be
be
very
very
subjective
subjective
and
and
controversial.
controversial
Scholl.
scholl
One
one
of
of
the
the
most
most
influential
influential
books
books
in
in
the
the
history
history
of
of
programming
programming
is
is
Design
design
Patterns
patterns
by
by
4
4
c
c
plus
plus
plus
plus
engineers
engineers
called
called
the
the
Gang
gang
of
of
4.
4
It
it
breaks
breaks
down
down
23
23
different
different
approaches
approaches
to
to
address
address
recurring
recurring
problems
problems
that
that
programmers
programmers
face,
face
which
which
are
are
categorized
categorized
as
as
creational
creational
patterns,
patterns
how
how
objects
objects
are
are
created,
created
structural
structural
patterns,
patterns
how
how
objects
objects
relate
relate
to
to
each
each
other,
other
And
and
behavioral
behavioral
patterns,
patterns
how
how
objects
objects
communicate
communicate
with
with
each
each
other.
other
Becoming
becoming
a
a
proficient
proficient
software
software
engineer
engineer
is
is
not
not
about
about
memorizing
memorizing
the
the
syntax
syntax
of
of
a
a
programming
programming
language,
language
but
but
rather
rather
the
the
to
to
solve
solve
problems
problems
with
with
it.
it
By
by
the
the
end
end
of
of
this
this
video,
video
you'll
you'll
understand
understand
a
a
variety
variety
of
of
different
different
patterns
patterns
for
for
solving
solving
problems
problems
as
as
they
they
relate
relate
to
to
modern
modern
app
app
developers.
developers
Before
before
we
we
get
get
started,
started
I
i
wanna
wanna
give
give
a
a
big
big
shout
shout
out
out
to
to
refactoring.guru.
refactoring.guru
They
they
gave
gave
me
me
permission
permission
to
to
use
use
some
some
of
of
their
their
graphics
graphics
that
that
explain
explain
design
design
patterns
patterns
better
better
than
than
anything
anything
else
else
out
out
there.
there
They're
they're
based
based
in
in
Ukraine
ukraine
and
and
it's
it's
seriously
seriously
one
one
of
of
the
the
coolest
coolest
programming
programming
websites
websites
on
on
the
the
Internet.
internet
Design
design
patterns
patterns
are
are
really
really
interesting
interesting
because
because
they're
they're
not
not
This
this
like
like
algorithms
algorithms
that
that
you
you
can
can
copy
copy
and
and
paste
paste
from
from
Stack
stack
Overflow.
overflow
You
you
actually
actually
need
need
to
to
use
use
your
your
brain
brain
to
to
implement
implement
them.
them
It
it
can
can
be
be
tempting
tempting
to
to
implement
implement
them
them
all
all
over
over
the
the
place,
place
but
but
when
when
used
used
improperly,
improperly
They
they
can
can
add
add
additional
additional
complexity
complexity
and
and
boiler
boiler
plate
plate
to
to
a
a
code
code
base.
base
The
the
book
book
is
is
not
not
the
the
bible,
bible
and
and
there
there
are
are
many
many
criticisms
criticisms
of
of
it.
it
Regardless,
regardless
knowing
knowing
how
how
To
to
recognize
recognize
design
design
patterns,
patterns
we'll
we'll
help
help
you
you
level
level
up
up
as
as
a
a
programmer.
programmer
The
the
first
first
pattern
pattern
we'll
we'll
look
look
at
at
is
is
singleton,
singleton
which
which
is
is
very
very
easy
easy
to
to
understand.
understand
It's
it's
a
a
type
type
of
of
object
object
that
that
can
can
only
only
the
the
instantiated
instantiated
ones.
ones
In
in
TypeScript,
typescript
we
we
might
might
implement
implement
a
a
singleton
singleton
class
class
called
called
settings
settings
to
to
represent
represent
the
the
global
global
app
app
settings
settings
data.
data
We'll
we'll
give
give
it
it
a
a
static
static
instance
instance
property
property
and
and
then
then
make
make
its
its
constructor
constructor
private
private
so
so
that
that
it
it
cannot
cannot
be
be
instantiated
instantiated
with
with
a
a
new
new
keyword.
keyword
We
we
then
then
create
create
a
a
static
static
get
get
instance
instance
method
method
that
that
will
will
check
check
to
to
see
see
If
if
the
the
instance
instance
has
has
already
already
been
been
created,
created
and
and
if
if
not,
not
it
it
will
will
create
create
a
a
new
new
one.
one
And
and
that
that
ensures
ensures
that
that
only
only
one
one
object
object
can
can
be
be
created.
created
That's
that's
great
great
and
and
all,
all
but
but
here's
here's
where
where
things
things
become
become
a
a
little
little
more
more
nuanced.
nuanced
In
in
JavaScript,
javascript
we
we
have
have
object
object
literals
literals
and
and
also
also
the
the
concept
concept
of
of
global
global
data,
data
and
and
objects
objects
are
are
passed
passed
around
around
by
by
reference.
reference
We
we
get
get
all
all
the
the
same
same
basic
basic
characteristics
characteristics
as
as
this
this
pattern
pattern
by
by
simply
simply
creating
creating
a
a
global
global
object.
object
The
the
pattern
pattern
itself
itself
is
is
really
really
just
just
extra
extra
boilerplate
boilerplate
that
that
we
we
don't
don't
need.
need
It's
it's
an
an
entirely
entirely
different
different
story
story
in
in
c
c
plus
plus
plus
plus
but
but
the
the
moral
moral
is
is
to
to
lean
lean
on
on
your
your
language's
language's
built
built
in
in
before
before
implementing
implementing
a
a
fancy
fancy
design
design
pattern.
pattern
Now
now
let's
let's
take
take
a
a
look
look
at
at
the
the
prototype
prototype
pattern,
pattern
which
which
is
is
just
just
a
a
fancy
fancy
word
word
for
for
clone.
clone
If
if
you've
you've
done
done
object
object
Minted
minted
programming,
programming
you
you
should
should
be
be
familiar
familiar
with
with
inheritance,
inheritance
where
where
a
a
class
class
can
can
be
be
extended
extended
with
with
a
a
subclass.
subclass
One
one
problem
problem
with
with
inheritance
inheritance
is
is
that
that
it
it
can
can
lead
lead
to
to
a
a
complex
complex
hierarchy
hierarchy
of
of
code.
code
The
the
prototype
prototype
pattern
pattern
is
is
an
an
alternative
alternative
way
way
to
to
implement
implement
inheritance,
inheritance
but
but
instead
instead
of
of
inheriting
inheriting
functionality
functionality
from
from
a
a
class,
class
it
it
comes
comes
from
from
an
an
object
object
that's
that's
already
already
been
been
created.
created
This
this
creates
creates
a
a
flat
flat
prototype
prototype
chain
chain
that
that
makes
makes
it
it
much
much
easier
easier
to
to
share
share
functionality
functionality
between
between
objects,
objects
especially
especially
in
in
a
a
dynamic
dynamic
language
language
like
like
JavaScript,
javascript
which
which
supports
supports
prototypal
prototypal
inheritance
inheritance
out
out
of
of
the
the
box.
box
Imagine
imagine
we
we
have
have
an
an
object
object
named
named
zombie.
zombie
This
this
is
is
our
our
prototype,
prototype
but
but
now
now
we
we
want
want
to
to
create
create
a
a
new
new
object
object
based
based
on
on
it
it
that
that
also
also
has
has
a
a
name.
name
We
we
can
can
do
do
that
that
with
with
object
object
create
create
by
by
passing
passing
the
the
zombie
zombie
as
as
the
the
prototype,
prototype
then
then
specify
specify
additional
additional
properties
properties
like
like
name
name
for
for
the
the
new
new
object.
object
The
the
interesting
interesting
thing
thing
is
is
that
that
if
if
you
you
log
log
this
this
object,
object
you'll
you'll
only
only
see
see
the
the
name
name
and
and
not
not
the
the
eat
eat
brains
brains
method.
method
However,
however
if
if
you
you
try
try
to
to
call
call
that
that
method
method
it
it
will
will
the
the
work.
work
That's
that's
because
because
JavaScript
javascript
will
will
go
go
up
up
the
the
prototype
prototype
chain
chain
until
until
it
it
reaches
reaches
the
the
root
root
looking
looking
for
for
any
any
methods
methods
or
or
properties
properties
on
on
the
the
parent
parent
objects.
objects
You
you
can
can
always
always
get
get
the
the
prototype
prototype
from
from
an
an
object
object
by
by
using
using
this
this
proto
proto
property.
property
However,
however
that's
that's
not
not
a
a
modern
modern
best
best
practice,
practice
and
and
instead
instead
you
you
should
should
use
use
object
object
get
get
prototype
prototype
of.
of
Now,
now
when
when
it
it
comes
comes
to
to
classes
classes
in
in
JavaScript,
javascript
prototype
prototype
refers
refers
to
to
its
its
constructor.
constructor
And
and
that
that
means
means
that
that
we
we
can
can
extend
extend
a
a
class
class
with
with
additional
additional
functions
functions
if
if
we
we
want
want
to.
to
However,
however
that's
that's
also
also
generally
generally
considered
considered
a
a
bad
bad
practice.
practice
Now,
now
let's
let's
switch
switch
gears
gears
to
to
the
the
builder
builder
pattern.
pattern
Imagine
imagine
you're
you're
running
running
a
a
hotdog
hotdog
stand,
stand
and
and
when
when
a
a
customer
customer
places
places
an
an
order,
order
they
they
need
need
to
to
tell
tell
you
you
everything
everything
they
they
want
want
in
in
the
the
sandwich
sandwich
in
in
the
the
constructor.
constructor
That
that
works,
works
but
but
it's
it's
kind
kind
of
of
hard
hard
To
to
keep
keep
track
track
of
of
all
all
these
these
options,
options
and
and
we
we
might
might
want
want
to
to
defer
defer
each
each
step
step
to
to
a
a
later
later
point.
point
With
with
the
the
builder
builder
pattern,
pattern
we
we
create
create
the
the
object
object
step
step
by
by
step
step
using
using
methods
methods
rather
rather
than
than
the
the
constructor,
constructor
and
and
we
we
could
could
even
even
delegate
delegate
the
the
building
building
logic
logic
to
to
an
an
entirely
entirely
different
different
class.
class
In
in
JavaScript,
javascript
we'll
we'll
have
have
each
each
method
method
return
return
this,
this
which
which
is
is
a
a
reference
reference
to
to
the
the
object
object
instance.
instance
That
that
allows
allows
us
us
to
to
implement
implement
method
method
chaining
chaining
where
where
we
we
instantiate
instantiate
an
an
object,
object
then
then
chain
chain
methods
methods
to
to
it,
it
but
but
always
always
get
get
the
the
object
object
as
as
the
the
return
return
value.
value
You'll
you'll
come
come
across
across
this
this
pattern
pattern
frequently
frequently
with
with
libraries
libraries
jQuery,
jquery
but
but
it's
it's
gone
gone
a
a
bit
bit
out
out
of
of
style
style
in
in
recent
recent
years.
years
Another
another
pattern
pattern
you
you
may
may
come
come
across
across
is
is
factory.
factory
Instead
instead
of
of
using
using
the
the
new
new
keyword
keyword
to
to
instantiate
instantiate
An
an
object,
object
you
you
use
use
a
a
function
function
or
or
method
method
to
to
do
do
it
it
for
for
you.
you
That
that
may
may
sound
sound
trivial,
trivial
but
but
here's
here's
a
a
practical
practical
example.
example
Let's
let's
imagine
imagine
we're
we're
building
building
a
a
cross
cross
platform
platform
app
app
that
that
runs
runs
on
on
both
both
iOS
ios
and
and
Android.
android
They
they
both
both
have
have
the
the
same
same
interface,
interface
but
but
in
in
our
our
code
code
we're
we're
doing
doing
a
a
bunch
bunch
of
of
conditional
conditional
checking
checking
to
to
determine
determine
which
which
button
button
to
to
show.
show
That's
that's
not
not
very
very
maintainable.
maintainable
Instead,
instead
we
we
can
can
create
create
a
a
sub
sub
class
class
or
or
function
function
that
that
will
will
determine
determine
which
which
object
object
to
to
instantiate.
instantiate
Now
now
instead
instead
of
of
repeating
repeating
the
the
same
same
logic,
logic
we
we
use
use
the
the
factory
factory
to
to
determine
determine
which
which
button
button
should
should
new
new
rendered.
rendered
Now,
now
we're
we're
ready
ready
to
to
look
look
at
at
the
the
first
first
structural
structural
pattern,
pattern
facade.
facade
A
a
facade
facade
is
is
the
the
face
face
of
of
a
a
building.
building
Inside
inside
that
that
building,
building
there's
there's
all
all
kinds
kinds
of
of
shenanigans,
shenanigans
corruption,
corruption
and
and
complexity
complexity
that
that
the
the
end
end
user
user
doesn't
doesn't
need
need
to
to
know
know
about.
about
A
a
facade
facade
is
is
basically
basically
just
just
a
a
simplified
simplified
API
api
to
to
hide
hide
other
other
low
low
level
level
details
details
in
in
your
your
code
code
base.
base
Let's
let's
Imagine
imagine
we
we
have
have
classes
classes
for
for
the
the
plumbing
plumbing
system
system
and
and
electrical
electrical
system,
system
and
and
inside
inside
of
of
them,
them
we
we
have
have
all
all
kinds
kinds
of
of
complex
complex
stuff
stuff
going
going
on
on
like
like
pressure
pressure
and
and
voltage.
voltage
The
the
people
people
living
living
in
in
the
the
house
house
don't
don't
need
need
access
access
to
to
these
these
low
low
level
level
details.
details
So
so
we
we
create
create
a
a
facade
facade
class
class
that
that
contains
contains
the
the
low
low
level
level
systems
systems
as
as
dependencies,
dependencies
but
but
then
then
simplifies
simplifies
their
their
operation.
operation
Like,
like
we
we
might
might
Combine
combine
all
all
of
of
the
the
electrical
electrical
and
and
plumbing
plumbing
details
details
into
into
a
a
single
single
method,
method
so
so
the
the
end
end
user
user
can
can
simply
simply
turn
turn
them
them
on
on
or
or
off
off
with
with
a
a
single
single
method.
method
Almost
almost
every
every
package
package
that
that
you
you
install
install
with
with
JavaScript
javascript
that
that
could
could
be
be
considered
considered
a
a
facade
facade
in
in
some
some
way.
way
Like,
like
jQuery
jquery
is
is
a
a
great
great
example
example
of
of
a
a
facade
facade
for
for
the
the
more
more
annoying
annoying
low
low
level
level
JavaScript
javascript
features.
features
The
the
next
next
structural
structural
pattern
pattern
The
the
look
look
at
at
is
is
proxy,
proxy
which
which
is
is
just
just
a
a
fancy
fancy
word
word
for
for
a
a
substitute.
substitute
Like
like
in
in
school,
school
you
you
might
might
have
have
a
a
substitute
substitute
teacher
teacher
to
to
replace
replace
the
the
real
real
thing.
thing
In
in
programming,
programming
you
you
can
can
replace
replace
a
a
target
target
object
object
with
with
the
the
proxy.
proxy
But
but
why
why
would
would
you
you
ever
ever
wanna
wanna
do
do
that?
that
Well,
well
a
a
great
great
case
case
study
study
is
is
the
the
reactivity
reactivity
system
system
in
in
Vue.
vue
Js.
js
In
in
Vue,
vue
you
you
create
create
data,
data
but
but
the
the
framework
framework
itself
itself
needs
needs
a
a
way
way
to
to
intercept
intercept
that
that
data
data
and
and
update
update
the
the
UI
ui
whenever
whenever
that
that
data
data
changes.
changes
The
the
way
way
vue
vue
handles
handles
that
that
is
is
by
by
replacing
replacing
the
the
original
original
object
object
with
with
a
a
proxy.
proxy
A
a
proxy
proxy
He
he
takes
takes
the
the
original
original
object
object
as
as
the
the
first
first
argument,
argument
then
then
a
a
handler
handler
as
as
the
the
second
second
argument.
argument
Inside
inside
of
of
which,
which
we
we
can
can
override
override
methods
methods
like
like
get
get
and
and
set,
set
which
which
allows
allows
us
us
to
to
run
run
code
code
whenever
whenever
a
a
property
property
is
is
accessed
accessed
just
just
on
on
the
the
object
object
were
were
changed.
changed
For
for
example,
example
inside
inside
of
of
set,
set
we
we
might
might
tell
tell
the
the
framework
framework
to
to
rerender,
rerender
then
then
use
use
reflect
reflect
to
to
update
update
the
the
data
data
on
on
the
the
original
original
object.
object
The
the
end
end
user
user
can
can
now
now
work
work
with
with
the
the
proxy
proxy
just
just
like
like
the
the
original
original
object,
object
but
but
it
it
can
can
trigger
trigger
these
these
side
side
effects
effects
behind
behind
the
the
scenes.
scenes
Proxies
proxies
are
are
also
also
commonly
commonly
used
used
when
when
you
you
have
have
a
a
very
very
large
large
object
object
that
that
would
would
be
be
expensive
expensive
to
to
duplicating
duplicating
memory.
memory
And
and
now
now
we're
we're
ready
ready
to
to
look
look
at
at
some
some
behavioral
behavioral
patterns,
patterns
starting
starting
with
with
iterator.
iterator
The
the
iterator
iterator
pattern
pattern
allows
allows
allows
allows
you
you
to
to
traverse
traverse
through
through
a
a
collection
collection
of
of
objects.
objects
Modern
modern
languages
languages
already
already
provide
provide
abstractions
abstractions
for
for
the
the
iterator
iterator
pattern
pattern
like
like
the
the
for
for
loop.
loop
When
when
you
you
loop
loop
over
over
an
an
array
array
of
of
items,
items
You're
you're
using
using
the
the
iterator
iterator
pattern,
pattern
but
but
one
one
thing
thing
that
that
really
really
chops
chops
my
my
ass
ass
about
about
JavaScript
javascript
is
is
that
that
there's
there's
no
no
built
built
in
in
range
range
function.
function
What
what
I
i
wish
wish
I
i
could
could
do
do
is
is
easily
easily
iterate
iterate
10
10
times
times
at
at
a
a
certain
certain
interval.
interval
We
we
can
can
actually
actually
do
do
that
that
fairly
fairly
easily
easily
by
by
implementing
implementing
our
our
own
own
iterator
iterator
pattern.
pattern
In
in
JavaScript,
javascript
you
you
can
can
do
do
that
that
by
by
defining
defining
an
an
object
object
that
that
has
has
a
a
next
next
method
method
on
on
it.
it
That
that
function
function
needs
needs
to
to
return
return
an
an
object
object
that
that
has
has
a
a
value,
value
which
which
would
would
be
be
the
the
current
current
value
value
in
in
the
the
loop,
loop
and
and
a
a
done
done
property
property
so
so
it
it
knows
knows
when
when
to
to
finish
finish
iterating.
iterating
In
in
this
this
case,
case
we
we
will
will
keep
keep
moving
moving
on
on
to
to
the
the
next
next
step
step
if
if
the
the
start
start
value
value
is
is
less
less
than
than
the
the
end
end
value.
value
But
but
for
for
each
each
iteration,
iteration
We
we
will
will
increment
increment
the
the
start
start
value
value
with
with
a
a
step.
step
Eventually,
eventually
the
the
start
start
will
will
be
be
greater
greater
than
than
the
the
end,
end
at
at
which
which
point
point
we
we
can
can
return
return
an
an
object
object
with
with
the
the
done
done
property
property
as
as
true,
true
and
and
that
that
tells
tells
JavaScript
javascript
to
to
stop
stop
iterating.
iterating
Now
now
a
a
cool
cool
technique
technique
here
here
is
is
that
that
we
we
can
can
add
add
symbol
symbol
iterator
iterator
to
to
this
this
object,
object
which
which
allows
allows
us
us
to
to
use
use
it
it
in
in
a
a
regular
regular
or
or
of
of
loop.
loop
At
at
the
the
end
end
of
of
the
the
day,
day
with
with
iteration,
iteration
you
you
start
start
with
with
a
a
collection
collection
and
and
then
then
write
write
some
some
code
code
that
that
determines
determines
how
how
to
to
get
get
from
from
the
the
beginning
beginning
to
to
the
the
end.
end
It's
it's
a
a
pull
pull
based
based
system.
system
Unlike
unlike
the
the
next
next
pattern
pattern
we'll
we'll
look
look
at,
at
observer,
observer
which
which
is
is
a
a
push
push
based
based
system.
system
The
the
observer
observer
pattern
pattern
allows
allows
many
many
objects
objects
to
to
subscribe
subscribe
to
to
events
events
that
that
but
but
are
are
broadcast
broadcast
by
by
another
another
object.
object
It's
it's
a
a
one
one
to
to
many
many
relationship.
relationship
In
in
the
the
real
real
world,
world
you
you
might
might
have
have
a
a
radio
radio
tower
tower
that
that
sends
sends
out
out
a
a
signal,
signal
then
then
a
a
bunch
bunch
of
of
receivers
receivers
who
who
listen
listen
men
men
at
at
the
the
same
same
time.
time
This
this
pattern
pattern
is
is
used
used
all
all
over
over
the
the
place
place
in
in
app
app
development,
development
like
like
in
in
Firebase,
firebase
when
when
your
your
data
data
changes
changes
on
on
the
the
server
server
while
while
your
your
client
client
apps
apps
are
are
inscribed
inscribed
to
to
it
it
and
and
automatically
automatically
update
update
it
it
with
with
the
the
latest
latest
data.
data
In
in
our
our
code
code
here,
here
I'm
i'm
going
going
to
to
bring
bring
in
in
the
the
RX
rx
JS
js
library
library
to
to
simplify
simplify
the
the
demonstration
demonstration
of
of
this
this
pattern.
pattern
It
it
provides
provides
a
a
subject
subject
class,
class
which
which
is
is
the
the
data
data
that
that
we
we
want
want
to
to
listen
listen
to.
to
Now
now
once
once
we
we
have
have
a
a
subject,
subject
we
we
can
can
add
add
multiple
multiple
subscriptions
subscriptions
to
to
it.
it
The
the
subject
subject
will
will
keep
keep
track
track
of
of
all
all
these
these
subscriptions
subscriptions
and
and
call
call
their
their
callback
callback
functions
functions
whenever
whenever
the
the
data
data
changes.
changes
Experiment
experiment
with
with
this
this
pattern
pattern
right
right
now
now
by
by
clicking
clicking
like
like
and
and
subscribe
subscribe
on
on
this
this
video.
video
Now
now
at
at
some
some
later
later
point,
point
we
we
can
can
call
call
the
the
next
next
method
method
to
to
push
push
a
a
new
new
value
value
to
to
the
the
subject.
subject
Whenever
whenever
that
that
happens,
happens
every
every
subscription
subscription
will
will
be
be
notified.
notified
Personally,
personally
I
i
like
like
To
to
think
think
of
of
this
this
as
as
a
a
loop
loop
that
that
unfolds
unfolds
over
over
the
the
dimension
dimension
of
of
time,
time
but
but
now
now
let's
let's
move
move
on
on
to
to
the
the
mediator
mediator
pattern.
pattern
A
a
mediator
mediator
is
is
like
like
a
a
middleman
middleman
or
or
broker.
broker
Imagine
imagine
we
we
have
have
a
a
class
class
for
for
airplane
airplane
and
and
runway.
runway
We
we
might
might
have
have
multiple
multiple
runways
runways
and
and
multiple
multiple
airplanes,
airplanes
and
and
somehow
somehow
we
we
need
need
to
to
figure
figure
out
out
if
if
an
an
airplane
airplane
is
is
clear
clear
to
to
land
land
on
on
a
a
given
given
Runway.
runway
Currently,
currently
to
to
do
do
that,
that
all
all
these
these
objects
objects
would
would
have
have
to
to
communicate
communicate
with
with
each
each
other.
other
We
we
have
have
a
a
many
many
to
to
many
many
relationship
relationship
that's
that's
very
very
dangerous
dangerous
both
both
in
in
real
real
life
life
and
and
in
in
programming.
programming
A
a
solution
solution
is
is
to
to
create
create
a
a
mediator,
mediator
like
like
an
an
air
air
traffic
traffic
controller,
controller
that
that
sits
sits
between
between
the
the
runways
runways
and
and
the
the
airplanes
airplanes
to
to
provide
provide
coordination
coordination
and
and
communication.
communication
Mission.
mission
Here's
here's
a
a
more
more
practical
practical
example.
example
In
in
the
the
Express
express
JS
js
web
web
framework,
framework
there
there
is
is
a
a
middleware
middleware
system.
system
You
you
have
have
incoming
incoming
requests
requests
and
and
outgoing
outgoing
responses.
responses
Middleware
middleware
sits
sits
in
in
the
the
middle
middle
by
by
intercepting
intercepting
Every
every
request,
request
like
like
an
an
airplane,
airplane
and
and
transforms
transforms
it
it
into
into
the
the
proper
proper
format
format
for
for
the
the
response,
response
the
the
runway.
runway
It
it
provides
provides
a
a
separation
separation
of
of
concerns
concerns
and
and
eliminates
eliminates
code
code
duplication.
duplication
And
and
that
that
brings
brings
us
us
Do
do
our
our
10th
10th
and
and
final
final
design
design
pattern,
pattern
state,
state
where
where
an
an
object
object
behaves
behaves
differently
differently
based
based
on
on
a
a
finite
finite
number
number
of
of
states.
states
In
in
your
your
code,
code
you've
you've
likely
likely
They
they
use
use
conditional
conditional
logic
logic
or
or
switch
switch
statements
statements
to
to
handle
handle
a
a
bunch
bunch
of
of
different
different
possibilities
possibilities
based
based
on
on
the
the
state
state
or
or
data
data
in
in
your
your
application.
application
Code
code
like
like
this
this
generally
generally
doesn't
doesn't
scale
scale
very
very
well.
well
The
the
state
state
pattern
pattern
allows
allows
you
you
to
to
start
start
with
with
1
1
base
base
class,
class
then
then
provide
provide
it
it
with
with
different
different
functionality
functionality
based
based
on
on
its
its
internal
internal
null
null
state.
state
The
the
idea
idea
is
is
related
related
to
to
finite
finite
state
state
machines
machines
and
and
libraries
libraries
like
like
xstate,
xstate
where
where
the
the
goal
goal
is
is
to
to
make
make
an
an
object's
object's
behavior
behavior
predictable
predictable
based
based
on
on
its
its
underlying
underlying
state.
state
In
in
this
this
example,
example
we
we
have
have
a
a
human
human
class
class
that
that
will
will
think
think
something
something
different
different
based
based
on
on
its
its
mood.
mood
Currently,
currently
we're
we're
doing
doing
that
that
with
with
a
a
switch
switch
statement,
statement
But
but
another
another
way
way
to
to
go
go
about
about
it
it
would
would
be
be
to
to
create
create
a
a
separate
separate
class
class
for
for
each
each
possible
possible
state.
state
Inside
inside
each
each
class,
class
we
we
will
will
have
have
an
an
identical
identical
method
method
that
that
behaves
behaves
differently.
differently
Now,
now
in
in
the
the
human
human
class,
class
we
we
set
set
the
the
state
state
as
as
a
a
property
property
and
and
whenever
whenever
that
that
method
method
is
is
called,
called
we
we
delegate
delegate
it
it
to
to
its
its
current
current
state.
state
That
that
means
means
whenever
whenever
the
the
state
state
changes,
changes
the
the
object
object
will
will
behave
behave
in
in
a
a
completely
completely
different
different
way,
way
but
but
at
at
the
the
same
same
time,
time
we
we
don't
don't
have
have
to
to
change
change
the
the
API
api
or
or
use
use
a
a
bunch
bunch
of
of
conditional
conditional
logic.
logic
I'm
i'm
gonna
gonna
keep
keep
things
things
simple
simple
and
and
wrap
wrap
it
it
up
up
there,
there
but
but
remember
remember
There
there
are
are
a
a
bunch
bunch
of
of
other
other
design
design
patterns
patterns
out
out
there
there
to
to
learn.
learn
Become
become
a
a
pro
pro
member
member
at
at
FireShip.
fireship
Io
io
to
to
learn
learn
how
how
to
to
apply
apply
patterns
patterns
like
like
this
this
in
in
real
real
applications.
applications
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speaker introduces the concept of a "monster" pattern in JavaScript, which involves creating a flat chain of a template and fixing certain attributes. They also discuss the use of object create, object get prototype, and builder patterns, as well as the importance of creating a facade class and using a push-based system for objects to subscribe to events. The speaker provides examples of how to create a pattern and thanks the audience for their time.
10 Design Patterns Explained in 10 Minutes
When you first become a junior developer, your code will look like Play Doh snakes. But as you progress to senior developer and learn about software design patterns, your code will look like the Sistine Chapel. But when you then progress to principal engineer, you'll realize that nobody wants to maintain the Sistine Chapel for a silly website and go back to in Play Doh snakes. In today's video, you'll learn about 10 different software design patterns along with the pros and cons of using them, which can be very subjective and controversial. Scholl. One of the most influential books in the history of programming is Design Patterns by 4 c plus plus engineers called the Gang of 4. It breaks down 23 different approaches to address recurring problems that programmers face, which are categorized as creational patterns, how objects are created, structural patterns, how objects relate to each other, And behavioral patterns, how objects communicate with each other. Becoming a proficient software engineer is not about memorizing the syntax of a programming language, but rather the to solve problems with it. By the end of this video, you'll understand a variety of different patterns for solving problems as they relate to modern app developers. Before we get started, I wanna give a big shout out to refactoring.guru. They gave me permission to use some of their graphics that explain design patterns better than anything else out there. They're based in Ukraine and it's seriously one of the coolest programming websites on the Internet. Design patterns are really interesting because they're not This like algorithms that you can copy and paste from Stack Overflow. You actually need to use your brain to implement them. It can be tempting to implement them all over the place, but when used improperly, They can add additional complexity and boiler plate to a code base. The book is not the bible, and there are many criticisms of it. Regardless, knowing how To recognize design patterns, we'll help you level up as a programmer. The first pattern we'll look at is singleton, which is very easy to understand. It's a type of object that can only the instantiated ones. In TypeScript, we might implement a singleton class called settings to represent the global app settings data. We'll give it a static instance property and then make its constructor private so that it cannot be instantiated with a new keyword. We then create a static get instance method that will check to see If the instance has already been created, and if not, it will create a new one. And that ensures that only one object can be created. That's great and all, but here's where things become a little more nuanced. In JavaScript, we have object literals and also the concept of global data, and objects are passed around by reference. We get all the same basic characteristics as this pattern by simply creating a global object. The pattern itself is really just extra boilerplate that we don't need. It's an entirely different story in c plus plus but the moral is to lean on your language's built in before implementing a fancy design pattern. Now let's take a look at the prototype pattern, which is just a fancy word for clone. If you've done object Minted programming, you should be familiar with inheritance, where a class can be extended with a subclass. One problem with inheritance is that it can lead to a complex hierarchy of code. The prototype pattern is an alternative way to implement inheritance, but instead of inheriting functionality from a class, it comes from an object that's already been created. This creates a flat prototype chain that makes it much easier to share functionality between objects, especially in a dynamic language like JavaScript, which supports prototypal inheritance out of the box. Imagine we have an object named zombie. This is our prototype, but now we want to create a new object based on it that also has a name. We can do that with object create by passing the zombie as the prototype, then specify additional properties like name for the new object. The interesting thing is that if you log this object, you'll only see the name and not the eat brains method. However, if you try to call that method it will the work. That's because JavaScript will go up the prototype chain until it reaches the root looking for any methods or properties on the parent objects. You can always get the prototype from an object by using this proto property. However, that's not a modern best practice, and instead you should use object get prototype of. Now, when it comes to classes in JavaScript, prototype refers to its constructor. And that means that we can extend a class with additional functions if we want to. However, that's also generally considered a bad practice. Now, let's switch gears to the builder pattern. Imagine you're running a hotdog stand, and when a customer places an order, they need to tell you everything they want in the sandwich in the constructor. That works, but it's kind of hard To keep track of all these options, and we might want to defer each step to a later point. With the builder pattern, we create the object step by step using methods rather than the constructor, and we could even delegate the building logic to an entirely different class. In JavaScript, we'll have each method return this, which is a reference to the object instance. That allows us to implement method chaining where we instantiate an object, then chain methods to it, but always get the object as the return value. You'll come across this pattern frequently with libraries jQuery, but it's gone a bit out of style in recent years. Another pattern you may come across is factory. Instead of using the new keyword to instantiate An object, you use a function or method to do it for you. That may sound trivial, but here's a practical example. Let's imagine we're building a cross platform app that runs on both iOS and Android. They both have the same interface, but in our code we're doing a bunch of conditional checking to determine which button to show. That's not very maintainable. Instead, we can create a sub class or function that will determine which object to instantiate. Now instead of repeating the same logic, we use the factory to determine which button should new rendered. Now, we're ready to look at the first structural pattern, facade. A facade is the face of a building. Inside that building, there's all kinds of shenanigans, corruption, and complexity that the end user doesn't need to know about. A facade is basically just a simplified API to hide other low level details in your code base. Let's Imagine we have classes for the plumbing system and electrical system, and inside of them, we have all kinds of complex stuff going on like pressure and voltage. The people living in the house don't need access to these low level details. So we create a facade class that contains the low level systems as dependencies, but then simplifies their operation. Like, we might Combine all of the electrical and plumbing details into a single method, so the end user can simply turn them on or off with a single method. Almost every package that you install with JavaScript that could be considered a facade in some way. Like, jQuery is a great example of a facade for the more annoying low level JavaScript features. The next structural pattern The look at is proxy, which is just a fancy word for a substitute. Like in school, you might have a substitute teacher to replace the real thing. In programming, you can replace a target object with the proxy. But why would you ever wanna do that? Well, a great case study is the reactivity system in Vue. Js. In Vue, you create data, but the framework itself needs a way to intercept that data and update the UI whenever that data changes. The way vue handles that is by replacing the original object with a proxy. A proxy He takes the original object as the first argument, then a handler as the second argument. Inside of which, we can override methods like get and set, which allows us to run code whenever a property is accessed just on the object were changed. For example, inside of set, we might tell the framework to rerender, then use reflect to update the data on the original object. The end user can now work with the proxy just like the original object, but it can trigger these side effects behind the scenes. Proxies are also commonly used when you have a very large object that would be expensive to duplicating memory. And now we're ready to look at some behavioral patterns, starting with iterator. The iterator pattern allows allows you to traverse through a collection of objects. Modern languages already provide abstractions for the iterator pattern like the for loop. When you loop over an array of items, You're using the iterator pattern, but one thing that really chops my ass about JavaScript is that there's no built in range function. What I wish I could do is easily iterate 10 times at a certain interval. We can actually do that fairly easily by implementing our own iterator pattern. In JavaScript, you can do that by defining an object that has a next method on it. That function needs to return an object that has a value, which would be the current value in the loop, and a done property so it knows when to finish iterating. In this case, we will keep moving on to the next step if the start value is less than the end value. But for each iteration, We will increment the start value with a step. Eventually, the start will be greater than the end, at which point we can return an object with the done property as true, and that tells JavaScript to stop iterating. Now a cool technique here is that we can add symbol iterator to this object, which allows us to use it in a regular or of loop. At the end of the day, with iteration, you start with a collection and then write some code that determines how to get from the beginning to the end. It's a pull based system. Unlike the next pattern we'll look at, observer, which is a push based system. The observer pattern allows many objects to subscribe to events that but are broadcast by another object. It's a one to many relationship. In the real world, you might have a radio tower that sends out a signal, then a bunch of receivers who listen men at the same time. This pattern is used all over the place in app development, like in Firebase, when your data changes on the server while your client apps are inscribed to it and automatically update it with the latest data. In our code here, I'm going to bring in the RX JS library to simplify the demonstration of this pattern. It provides a subject class, which is the data that we want to listen to. Now once we have a subject, we can add multiple subscriptions to it. The subject will keep track of all these subscriptions and call their callback functions whenever the data changes. Experiment with this pattern right now by clicking like and subscribe on this video. Now at some later point, we can call the next method to push a new value to the subject. Whenever that happens, every subscription will be notified. Personally, I like To think of this as a loop that unfolds over the dimension of time, but now let's move on to the mediator pattern. A mediator is like a middleman or broker. Imagine we have a class for airplane and runway. We might have multiple runways and multiple airplanes, and somehow we need to figure out if an airplane is clear to land on a given Runway. Currently, to do that, all these objects would have to communicate with each other. We have a many to many relationship that's very dangerous both in real life and in programming. A solution is to create a mediator, like an air traffic controller, that sits between the runways and the airplanes to provide coordination and communication. Mission. Here's a more practical example. In the Express JS web framework, there is a middleware system. You have incoming requests and outgoing responses. Middleware sits in the middle by intercepting Every request, like an airplane, and transforms it into the proper format for the response, the runway. It provides a separation of concerns and eliminates code duplication. And that brings us Do our 10th and final design pattern, state, where an object behaves differently based on a finite number of states. In your code, you've likely They use conditional logic or switch statements to handle a bunch of different possibilities based on the state or data in your application. Code like this generally doesn't scale very well. The state pattern allows you to start with 1 base class, then provide it with different functionality based on its internal null state. The idea is related to finite state machines and libraries like xstate, where the goal is to make an object's behavior predictable based on its underlying state. In this example, we have a human class that will think something different based on its mood. Currently, we're doing that with a switch statement, But another way to go about it would be to create a separate class for each possible state. Inside each class, we will have an identical method that behaves differently. Now, in the human class, we set the state as a property and whenever that method is called, we delegate it to its current state. That means whenever the state changes, the object will behave in a completely different way, but at the same time, we don't have to change the API or use a bunch of conditional logic. I'm gonna keep things simple and wrap it up there, but remember There are a bunch of other design patterns out there to learn. Become a pro member at FireShip. Io to learn how to apply patterns like this in real applications. Thanks for watching, and I will see you in the next one.
The speaker introduces the concept of a "monster" pattern in JavaScript, which involves creating a flat chain of a template and fixing certain attributes. They also discuss the use of object create, object get prototype, and builder patterns, as well as the importance of creating a facade class and using a push-based system for objects to subscribe to events. The speaker provides examples of how to create a pattern and thanks the audience for their time.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : 10 Design Patterns Explained in 10 Minutes 
        and a small summary : The speaker introduces the concept of a "monster" pattern in JavaScript, which involves creating a flat chain of a template and fixing certain attributes. They also discuss the use of object create, object get prototype, and builder patterns, as well as the importance of creating a facade class and using a push-based system for objects to subscribe to events. The speaker provides examples of how to create a pattern and thanks the audience for their time.
        [/INST]
        
        Generate the video : When you first become a junior developer, your code will look like Play Doh snakes. But as you progress to senior developer and learn about software design patterns, your code will look like the Sistine Chapel. But when you then progress to principal engineer, you'll realize that nobody wants to maintain the Sistine Chapel for a silly website and go back to in Play Doh snakes. In today's video, you'll learn about 10 different software design patterns along with the pros and cons of using them, which can be very subjective and controversial. Scholl. One of the most influential books in the history of programming is Design Patterns by 4 c plus plus engineers called the Gang of 4. It breaks down 23 different approaches to address recurring problems that programmers face, which are categorized as creational patterns, how objects are created, structural patterns, how objects relate to each other, And behavioral patterns, how objects communicate with each other. Becoming a proficient software engineer is not about memorizing the syntax of a programming language, but rather the to solve problems with it. By the end of this video, you'll understand a variety of different patterns for solving problems as they relate to modern app developers. Before we get started, I wanna give a big shout out to refactoring.guru. They gave me permission to use some of their graphics that explain design patterns better than anything else out there. They're based in Ukraine and it's seriously one of the coolest programming websites on the Internet. Design patterns are really interesting because they're not This like algorithms that you can copy and paste from Stack Overflow. You actually need to use your brain to implement them. It can be tempting to implement them all over the place, but when used improperly, They can add additional complexity and boiler plate to a code base. The book is not the bible, and there are many criticisms of it. Regardless, knowing how To recognize design patterns, we'll help you level up as a programmer. The first pattern we'll look at is singleton, which is very easy to understand. It's a type of object that can only the instantiated ones. In TypeScript, we might implement a singleton class called settings to represent the global app settings data. We'll give it a static instance property and then make its constructor private so that it cannot be instantiated with a new keyword. We then create a static get instance method that will check to see If the instance has already been created, and if not, it will create a new one. And that ensures that only one object can be created. That's great and all, but here's where things become a little more nuanced. In JavaScript, we have object literals and also the concept of global data, and objects are passed around by reference. We get all the same basic characteristics as this pattern by simply creating a global object. The pattern itself is really just extra boilerplate that we don't need. It's an entirely different story in c plus plus but the moral is to lean on your language's built in before implementing a fancy design pattern. Now let's take a look at the prototype pattern, which is just a fancy word for clone. If you've done object Minted programming, you should be familiar with inheritance, where a class can be extended with a subclass. One problem with inheritance is that it can lead to a complex hierarchy of code. The prototype pattern is an alternative way to implement inheritance, but instead of inheriting functionality from a class, it comes from an object that's already been created. This creates a flat prototype chain that makes it much easier to share functionality between objects, especially in a dynamic language like JavaScript, which supports prototypal inheritance out of the box. Imagine we have an object named zombie. This is our prototype, but now we want to create a new object based on it that also has a name. We can do that with object create by passing the zombie as the prototype, then specify additional properties like name for the new object. The interesting thing is that if you log this object, you'll only see the name and not the eat brains method. However, if you try to call that method it will the work. That's because JavaScript will go up the prototype chain until it reaches the root looking for any methods or properties on the parent objects. You can always get the prototype from an object by using this proto property. However, that's not a modern best practice, and instead you should use object get prototype of. Now, when it comes to classes in JavaScript, prototype refers to its constructor. And that means that we can extend a class with additional functions if we want to. However, that's also generally considered a bad practice. Now, let's switch gears to the builder pattern. Imagine you're running a hotdog stand, and when a customer places an order, they need to tell you everything they want in the sandwich in the constructor. That works, but it's kind of hard To keep track of all these options, and we might want to defer each step to a later point. With the builder pattern, we create the object step by step using methods rather than the constructor, and we could even delegate the building logic to an entirely different class. In JavaScript, we'll have each method return this, which is a reference to the object instance. That allows us to implement method chaining where we instantiate an object, then chain methods to it, but always get the object as the return value. You'll come across this pattern frequently with libraries jQuery, but it's gone a bit out of style in recent years. Another pattern you may come across is factory. Instead of using the new keyword to instantiate An object, you use a function or method to do it for you. That may sound trivial, but here's a practical example. Let's imagine we're building a cross platform app that runs on both iOS and Android. They both have the same interface, but in our code we're doing a bunch of conditional checking to determine which button to show. That's not very maintainable. Instead, we can create a sub class or function that will determine which object to instantiate. Now instead of repeating the same logic, we use the factory to determine which button should new rendered. Now, we're ready to look at the first structural pattern, facade. A facade is the face of a building. Inside that building, there's all kinds of shenanigans, corruption, and complexity that the end user doesn't need to know about. A facade is basically just a simplified API to hide other low level details in your code base. Let's Imagine we have classes for the plumbing system and electrical system, and inside of them, we have all kinds of complex stuff going on like pressure and voltage. The people living in the house don't need access to these low level details. So we create a facade class that contains the low level systems as dependencies, but then simplifies their operation. Like, we might Combine all of the electrical and plumbing details into a single method, so the end user can simply turn them on or off with a single method. Almost every package that you install with JavaScript that could be considered a facade in some way. Like, jQuery is a great example of a facade for the more annoying low level JavaScript features. The next structural pattern The look at is proxy, which is just a fancy word for a substitute. Like in school, you might have a substitute teacher to replace the real thing. In programming, you can replace a target object with the proxy. But why would you ever wanna do that? Well, a great case study is the reactivity system in Vue. Js. In Vue, you create data, but the framework itself needs a way to intercept that data and update the UI whenever that data changes. The way vue handles that is by replacing the original object with a proxy. A proxy He takes the original object as the first argument, then a handler as the second argument. Inside of which, we can override methods like get and set, which allows us to run code whenever a property is accessed just on the object were changed. For example, inside of set, we might tell the framework to rerender, then use reflect to update the data on the original object. The end user can now work with the proxy just like the original object, but it can trigger these side effects behind the scenes. Proxies are also commonly used when you have a very large object that would be expensive to duplicating memory. And now we're ready to look at some behavioral patterns, starting with iterator. The iterator pattern allows allows you to traverse through a collection of objects. Modern languages already provide abstractions for the iterator pattern like the for loop. When you loop over an array of items, You're using the iterator pattern, but one thing that really chops my ass about JavaScript is that there's no built in range function. What I wish I could do is easily iterate 10 times at a certain interval. We can actually do that fairly easily by implementing our own iterator pattern. In JavaScript, you can do that by defining an object that has a next method on it. That function needs to return an object that has a value, which would be the current value in the loop, and a done property so it knows when to finish iterating. In this case, we will keep moving on to the next step if the start value is less than the end value. But for each iteration, We will increment the start value with a step. Eventually, the start will be greater than the end, at which point we can return an object with the done property as true, and that tells JavaScript to stop iterating. Now a cool technique here is that we can add symbol iterator to this object, which allows us to use it in a regular or of loop. At the end of the day, with iteration, you start with a collection and then write some code that determines how to get from the beginning to the end. It's a pull based system. Unlike the next pattern we'll look at, observer, which is a push based system. The observer pattern allows many objects to subscribe to events that but are broadcast by another object. It's a one to many relationship. In the real world, you might have a radio tower that sends out a signal, then a bunch of receivers who listen men at the same time. This pattern is used all over the place in app development, like in Firebase, when your data changes on the server while your client apps are inscribed to it and automatically update it with the latest data. In our code here, I'm going to bring in the RX JS library to simplify the demonstration of this pattern. It provides a subject class, which is the data that we want to listen to. Now once we have a subject, we can add multiple subscriptions to it. The subject will keep track of all these subscriptions and call their callback functions whenever the data changes. Experiment with this pattern right now by clicking like and subscribe on this video. Now at some later point, we can call the next method to push a new value to the subject. Whenever that happens, every subscription will be notified. Personally, I like To think of this as a loop that unfolds over the dimension of time, but now let's move on to the mediator pattern. A mediator is like a middleman or broker. Imagine we have a class for airplane and runway. We might have multiple runways and multiple airplanes, and somehow we need to figure out if an airplane is clear to land on a given Runway. Currently, to do that, all these objects would have to communicate with each other. We have a many to many relationship that's very dangerous both in real life and in programming. A solution is to create a mediator, like an air traffic controller, that sits between the runways and the airplanes to provide coordination and communication. Mission. Here's a more practical example. In the Express JS web framework, there is a middleware system. You have incoming requests and outgoing responses. Middleware sits in the middle by intercepting Every request, like an airplane, and transforms it into the proper format for the response, the runway. It provides a separation of concerns and eliminates code duplication. And that brings us Do our 10th and final design pattern, state, where an object behaves differently based on a finite number of states. In your code, you've likely They use conditional logic or switch statements to handle a bunch of different possibilities based on the state or data in your application. Code like this generally doesn't scale very well. The state pattern allows you to start with 1 base class, then provide it with different functionality based on its internal null state. The idea is related to finite state machines and libraries like xstate, where the goal is to make an object's behavior predictable based on its underlying state. In this example, we have a human class that will think something different based on its mood. Currently, we're doing that with a switch statement, But another way to go about it would be to create a separate class for each possible state. Inside each class, we will have an identical method that behaves differently. Now, in the human class, we set the state as a property and whenever that method is called, we delegate it to its current state. That means whenever the state changes, the object will behave in a completely different way, but at the same time, we don't have to change the API or use a bunch of conditional logic. I'm gonna keep things simple and wrap it up there, but remember There are a bunch of other design patterns out there to learn. Become a pro member at FireShip. Io to learn how to apply patterns like this in real applications. Thanks for watching, and I will see you in the next one.
        