Refactoring Guru is awesome. I found them a while ago and read thru their refactoring & design patterns content. It mirrors the standard books on those topics. And their cartoons for each pattern are REALLY helpful.
Hello from the author! Thank you folks for all the kind words of support. I'm flattered, really. Hopefully I'll find some way to work on the new refactoring section amidst this madness that's going on in my country. Cheers!
I bought both the book design patterns and the course without even looking through this video. The site just screamed quality. Also, really hope that things turns out great for you in the end and the madness in your country stops.
Love what I’m reading on the site so far! There’s one aspect of refactoring and clean code that’s just utterly tragic: many programmers don’t really appreciate well-designed code when they see it. Or at least more junior programmers anyway. A lot of the insight that goes into expert code design can just appear to be some kind of accidental happy coincidence to folks who don’t know any better. Or even worse, like an undesirable expenditure of extra lines of code. I don’t think we, as an industry, spend enough time discussing the extreme value of writing clear, robust, self-documenting code. We definitely spend a lot of time stressing the importance of learning a tiny bit about every new framework that pops up.
Funny that I'm already using most of them in some form without even knowing about them. I always avoided learning design patterns except of the simple ones because of the overly theoretical explanations in most articles. But this isn't the case in this video, everything explained in the most simpliest way with good examples. Very helpful!
If my professor wasn't such a hard working guy on forcing us to learn these pos patterns I probably would've given up on my own. The book is pretty difficult to read, at least in my experience, if you don't have a good guide it can be just painful in general. I also hate reading so xd.
Interestingly enough, I keep skimming the text the first time and reading hate, seeing love and then reading it a second time. Edit: At least I did it twice.
I always knew if I was lazy and waited long enough that Fireship would teach me about design patterns. 😂 Truly the best source for simplifying complex concepts.
Not enough. I've been watching courses on design patterns for years, and still don't know them. The hardest part is to recognise when to use one, but for that you really need to know everything about them. 10 minutes won't be enough.
@@DavidSmith-ef4eh yeah you're absolutely right, but my point is in these 2 scenarios : 1) don't know what a design pattern is, neither categories of design pattern, neither the overall utility of each one 2) learn the *overall concepts* of common design patterns In the first scenario, I don't have enough knowledge to even think about using a pattern But in the second one, I can at least consider to implement some patterns when I code So I think this video is perfect for people like me EDIT: I didn't say this video is enough to *master* design patterns (it's up to the developer to learn them), but it's enough to *know* them
FINALLY Design patterns are super interesting and it's especially helpful that this is in Typescript and JavaScript. Most articles about this use examples in Java and pointing out that some are overly complicated if you're using JavaScript is great. Thanks for making a video explaining all of these with pros and cons. 🔥🚀
Yeah, some patterns emerging from Java were because of the OOP strictness it has and don't necessarily make sense outside of that constraint. Seeing these patterns make sense in a freeing language such as JS makes them feel right.
Mind blown are the only two words I can think right now. I have been dabbling in understanding these design patterns for a while now but this is the simplest yet clear video I have come across for design patterns. Loved it!
This is the first thing I learned the hard way while entering in the professional world, thinking why haven't I been teach that before ! Glad to finally see it here !
I always thought of design patterns as something really complex, convoluted stuff that would be so hard to learn, and only for really smart people to learn. So I was kinda intimidated to start learning it. But, this video made me realize that it looks so fun, and even I could do it. Thanks for giving me the confidence and keep making these world-class, wonderful videos.
I think the issue is that a lot of resources makes a lot of assumptions and theoretical problems that aren't realistic, so it it's hard to apply to your problem if you don't even know where to begin, and often overblown in a lot of cases. Design patterns are guidelines and doesn't need to be implemented 100% the same as books explain it. Books often try to cover a lot of use-cases that you may not even need to think about.
@@dealloc Yeah, you're right. A lot of books go into details that are irrelevant in practical application. But, I guess that's why they are books, cuz it lets you go into the rabbit hole of stuff - if you want to. As you said, since these books make a lot of assumptions about your current knowledge, it makes things harder for beginners. 👍
Could you do another one about some additional patterns? - Dependency injection - Adapter/Translator - Bridge/Opaque Pointer/Pimpl - RAII - Visitor And maybe a separate video about concurrency patterns.
I have a BS in Computer Science from Drexel, and learned a lot of this back then, and this is a very nice overview/refresher. I can tell you that at least in my career, I've rarely worked with engineers who think and talk about code and problems they're solving in these types of terms. A lot of time, explicit choices of pattern usage comes after the fact, if at all. Sometimes the hardest part is identifying when a pattern is in use, especially if it spans multiple files and/or directories. Even as a senior engineer or architect, I struggle with that. It really does require a shift in mindset (both individual and the team you work on), that touches not just on when you're typing out the code, but when you're planning or refining the work that needs to be done. Teams which can talk about these things ahead of time and document it in their ticketing system will have a much easier time when it comes to code review and pull requests, and QA engineers will have an easier time following along and identifying/pointing out potential areas of incorrectness when bugs are encountered. And for the sake of junior engineers, or engineers who've never taken a course on design patterns, document in the code itself when a particular pattern is being used. A link to the e-book, or at least the name of the book/place/blog/whatever where it originated can save everyone time and energy.
It's super interesting when you learn Design patterns really late in your CS Career. You realize that you already implemented some of those patterns without knowing it or you already met a problem that would have been solved with one of those patterns
The way you describe this stuff is so pragmatic. As much as I appreciate everyone's work on educational content, on here, this type of pragmatic approach is exactly what is missing from the majority of videos on these topics.
Content like this, code reports and 100 seconds make this literally the best channel ive seen in many years. Been here even before you had 1 million subscribers and let me say you deserve 10 millions subs!!!
I’m just starting out in programming and this is the kind of thing I’m looking for. This seems WAY more essential to coding than learning the syntax. Yeah you need to know how your tools work and its better and faster to know the right tool but if you don’t know how to build the house it really doesn’t matter.
Funny thing how I have used some of these patterns over the years but under different names: - Singleton: static / global class - Builder: classic object definition from C++ - Factory: I used to refer to this as "builder" and many of my older codes named factories as "builder" - Facade: encapsulation - Proxy: wrapper - Observer: event listener - Mediator: router
@David Smith Well, I think HTML is a good example of Composite pattern. When a browser wants to calculate size of an element (like 'div') in page, it does not matter whether that 'div' is a container of more elements or if it contains no child elements. The browser treats a "container div" and a "non-container div" the same way.
In videogames is usted a lot. Unity and Unreal Engine is structured that way. Why? For example there can be enemies that walk, fly, hit or shoot, and allies that can also walk, fly, hit or shoot. If you want to implement those features only once and not end with a god class, you cannot do it with just inheritance, because there is not a clear hierarchy. One good way to do it is by creating a "gameobject" that can have components, and then create the walk, fly, hit, shoot, and behavioral components (and the behavioral component would delegate the enemy or ally using composition)
you deserve 2 trophies, one for condensing all this content in 10 minutes with this level of clarity (might be biased since I already knew about these design patterns), and the second one just in case you lose the first one.
Pure synchronization! I've been studying patterns for the last two weeks and some days ago I was reading through Refactoring Guru. Now you guys, one of my favorite youtube channels, made a video about it. Thanks!
It's really hard to make examples that are complex enough that it makes sense to use the feature being taught, but simple enough to understand quickly. You nail it every time.
Thanks Jeff for this value-packed content. Once you understand the value of these design patterns, it is hard to go back to the Play-Doh snakes. Even in my tutorials, sometimes I know that writing Play-doh snakes will be faster and easier for beginners to understand, but I still can't help myself from not spending extra 15-30 minutes to implement everything based on best practices. It's important to get started with the right foot.
Such a much needed video! I feel that programmers today gloss over these fundamental software design patterns because they are already given features that solve them out of the box with high level languages. And so many never learn why those features exist and are still prone to recreating basic design flaws in code. And the issue with giving them a textbook like Design Patterns by gang of four is that although the concepts are timeless and fundamental, the terminology is outdated and many of the patterns in the book are eased in higher languages with powerful language-native abstractions So there’s a discrepancy where for newer programmers the patterns need to be translated into modern terminology and shown what modern language features correspond to which patterns!
For anyone confused as I was for a long time... The factory example in the video is not the design pattern called Factory Method (Virtual Constructor). The book talks about a Template Pattern that behaves different, like a factory. The name factory can be associated with a class that creates another class, making even the Builder Pattern a factory. The difference of the Smple Factory (the one showed in the video) with the design pattern is the Open Closed Principle. The Factory Method does not break the principle but Simple Factory does. Sorry for the long comment, I recently learned the difference and thought it was good to share
At 2:05 In JS, objects aren’t passed by reference. Their reference ID is copied into a new value and that is passed. That’s why you can update properties but not the entire object. Small but important distinction
I am an indie game developer, I think that the builder pattern works great for all the objects, the mediator is great for inputs and controlling objects, the state is good for controlling the game flow, but like you said, it works on step bases and its very easy to mess.
Simpler iterator pattern using generator functions: function* range(from, to, step = 1) { for(let i = from; i < to; i += step) { yield i; } } Or you know... you can just use for loop directly. :)
You can even use a generator for the iterator implementation to make the range function an iterable. It's the perfect use case for a generator! const range = (start, end, step = 1) => ({ *[Symbol.iterator]() { for (let i = start; i
I'm just starting with programming and just when I think I know what I need to know, you show me something new to learn. Thank alot man you are teaching literally more than half of what I know.
I'd love to see another video covering more design patterns. As a new programmer this makes me feel like I'm not completely lost on at sea on if what I'm doing is a good way to design my code instead of just randomly doing the first idea that pops in my head or contemplating it for hours without getting anything done.
Singletons are useful for logging & error reporting. ActionPack, an important piece of rails, uses Singletons for route deprecation and Mime type identification. Sprinkling Singleton spice over a codebase would suck probably, but they aren't useless.
They are a colossal pita to test (to test an object you may need a fresh copy of the object many times) and so not recommended at a few minor places like google ..
Very interesting, I've been programming for around 10 years now and just now am learning the names of these patterns I've been using for years haha. The only one that was completely new was the prototype pattern, I come from a mostly java reverse engineering background so I've always thought of that kind of like proxies.
The facade pattern is extremely underrated. It does way more than just abstract away complex logic. Its real super power is to make your code more testable with dependency injection. One important thing to remember is that design patterns are not all or nothing. Each of the patterns are often used together, and some are just specialized versions of more fundamental patterns. A bit like how all multiples of 4 are also multiples of 2.
Holy shit this is EXACTLY what I need, this is like my personal bleeding edge of "technologies" regarding programming, that I am just about to learn, right when I actually run into problems that are solved by some of these design philosophies To keep it simple: Awesome video :D
@@tropicaldog430 He just added setters which can be chained. With the builder pattern, you have a dedicated builder class with these setters. In the end, you call build() and receive the object you wanted, usually immutable.
Yesterday I discovered design patterns in programming. I thought I'll look into it further and today this is the first video on my youtube. The universe sometimes listen to you
I love your videos, but the builder pattern as shown here is very different from the common interpretation of it. The point of the builder pattern is to separate the representation of an object from its construction process. This involves separating it into two classes, ie, Car, and CarBuilder. You create a CarBuilder, and use its methods, typically chained, which eventually give you a Car. This pattern is very common in Java and C# but also seen in other languages like C/C++ and Rust. Of course, this pattern is uncommon in JS where the most popular way to create an object is to pass an init/config object to a constructor or factory method, thanks to the object literal syntax.
Things are interchangeable, you could also create a config/init object in those other languages and remove the builder pattern. It’s just a little more verbose than js but is totally okay. You can also use the functional options pattern to create objects. They are so much way of creating objects 😅
Just yesterday I searched for design patterns for the first time and also stumbled across Refactoring Guru. Are you spying on my work laptop? Not complaining! Thanks for delivering this video just when I needed it. :D
Great video, although I low-key expected some manner of criticism given how easy it is to overuse these patterns. What often happens is that people use these so frequently that rather than genuinely trying to provide a solution to a problem, they try to re-shape the problem in a way that there is an obvious cookie-cutter solution to it. That is of course not the problem of the patterns themselves, so I understand that you make no mention of this. Giving some examples of when _not_ to use GOF patterns would be immensely helpful though, in a future video perhaps?
You nailed it at 1:22. Overused, too much boilerplate, gotta open 7 new tabs to even see what’s happening. It’s really just gatekeeping. Like, “they can’t replace me, nobody will ever figure out my genius design pattern”
Excellent video. Definitely the best explanation of avoiding switch /case hell out there. A great reason I read about why you should use the factory pattern in JS ( even when it's as simple as function taking a Class returning new Class), is because making changes from that point onwards just involves altering the function, i.e. in one place. But changing every "new Class" instantiation to a factory can be a huge a breaking change.
I'm a copy/paste warrior and after looking at their site, I'm definitely a "Template"-type design user. I'm not so creative on my own, but I'm usually pretty good at having code up in one window and then completely rewriting it to be better on a second window.
Same here, I make $32,400 profits on my investment since I started trading with Expert Christine Norine Martin, her trading strategies are top notch. I’m winning consistently trading with Mrs Christine. She’s really the best broker. I've made a lot of profit investing with her.
Hey, great video ! For the iterator pattern, you can also use a generator function (*function) and the yield keyword, like this : // the * is essential *[Symbol.iterator]() { for(let i = start ; i != stop ; i+=step) { yield i; } } Feel free to check on MDN how generator functions work, it's pretty interesting :)
I always find it amazing how you can talk for 11 minutes and 3 seconds without ever breathing. I have to say it makes following along harder than it needs to be (I think it's ok if you're videos are a bit longer: the power of the pause in public speaking)
Thanks very much. I am very much a "noob" at programming and am cursed with knowing a little of a lot of those examples and so find it difficult to get my head into a fixed pattern of writing codes. After watching that I take some solace knowing this is common. On a higher level I get what you are saying, and your examples are good, but my brain goes into overload as I am not familiar with the terms used and you are going at it fairly fast. (luckily I can "rewind" and watch things again and again.
4:57 "A facade is the face of a building. Inside that building there's all kinds of shenanigans, corruption, and complexity that the user doesn't need to know about." OMG, I almost fell out of my chair with that one. This is like British humor++.
Singleton: This is a creational pattern that allows creating only one instance of a class throughout the application. This pattern is useful when we want to limit the number of instances of a particular class in the program. Prototype: This pattern involves creating a new object based on an existing object, also known as cloning. This pattern is useful when we need to create many objects with similar attributes or functionality. Builder: This is another creational pattern that separates the construction of a complex object from its representation. This pattern is useful when we need to create an object that requires several steps to be constructed. Factory: This pattern involves creating objects without specifying the exact class of the object that will be created. This pattern is useful when we need to create objects based on a certain condition or logic. Facade: This is a structural pattern that provides a simple interface to a complex system of classes. This pattern is useful when we want to simplify the use of a complex system by providing a high-level interface. Proxy: This pattern involves creating a placeholder object that represents another object. This pattern is useful when we want to control the access to an object, add extra functionality Iterator Pattern: The Iterator Pattern provides a way to access the elements of an object sequentially without exposing its underlying representation. It defines an object that encapsulates the collection of elements and an interface for accessing them one by one in a specific order. Observer Pattern: The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. It provides a way for objects to communicate and stay in sync with each other. Mediator Pattern: The Mediator Pattern defines an object that encapsulates how a set of objects interact with each other. It promotes loose coupling by keeping objects from referring to each other explicitly and allows them to communicate through the mediator. State Pattern: The State Pattern allows an object to alter its behavior when its internal state changes. It encapsulates state-specific behavior into separate classes and delegates to the object representing the current state to handle requests.
These things are so important to know! Even if you don't use any of this, sometimes u can use patterns like this in a smaller way or solve another problem better just because u know whats possible
My favorite design patterns are ones that solve development problems. If you use VS Code for vanilla JS like me, you'll notice code hinting falls apart sometimes when passing a custom class to a function, thus changing the scope. One trick I use is class constructors with a self-creation clause at the beginning: constructor(input) { if (input instanceof ClassName) return input; }-This allows you to "cast" a variable as that class by using myVar = new ClassName(myVar); which seems unnecessary because it doesn't actually do anything but it's enough to let VS Code know what class that variable has since you don't have typed parameters in JS, thus fixing the issue of missing code hints. Microsoft could probably fix this issue with a more robust JS engine but it's fun finding work-arounds to common problems nonetheless.
Either I am too lucky or Jeff knows what's going in my mind, as yesterday I was searching for design patterns and now just saw the best explanation I think I could ever get.
Thanks for showing this! This video fell on my recommendations when I wanted to check about design patterns since I am mostly fumbling by myself with regards to programming.
I think explaining those 10 design patterns in 10 mins is substantially much harder than trying to explain it in 60 mins. Great work as always.
i see your point
smart cat
How did you figure that out
the floor is made of floor damn
Any books to recommend ?
Refactoring Guru is awesome. I found them a while ago and read thru their refactoring & design patterns content. It mirrors the standard books on those topics. And their cartoons for each pattern are REALLY helpful.
Hello from the author! Thank you folks for all the kind words of support. I'm flattered, really. Hopefully I'll find some way to work on the new refactoring section amidst this madness that's going on in my country. Cheers!
@@shvetsgroup ❤️👍
I second this comment. I have also purchased the refactoring course 👍
I bought both the book design patterns and the course without even looking through this video. The site just screamed quality. Also, really hope that things turns out great for you in the end and the madness in your country stops.
Love what I’m reading on the site so far!
There’s one aspect of refactoring and clean code that’s just utterly tragic: many programmers don’t really appreciate well-designed code when they see it. Or at least more junior programmers anyway. A lot of the insight that goes into expert code design can just appear to be some kind of accidental happy coincidence to folks who don’t know any better. Or even worse, like an undesirable expenditure of extra lines of code.
I don’t think we, as an industry, spend enough time discussing the extreme value of writing clear, robust, self-documenting code. We definitely spend a lot of time stressing the importance of learning a tiny bit about every new framework that pops up.
Funny that I'm already using most of them in some form without even knowing about them. I always avoided learning design patterns except of the simple ones because of the overly theoretical explanations in most articles. But this isn't the case in this video, everything explained in the most simpliest way with good examples. Very helpful!
If my professor wasn't such a hard working guy on forcing us to learn these pos patterns I probably would've given up on my own. The book is pretty difficult to read, at least in my experience, if you don't have a good guide it can be just painful in general.
I also hate reading so xd.
I remember recommending this topic earlier. Glad to see it come to fruition. Exactly what I needed.
Oooooooh my dog, what's up?
Ugh, I love it when people simplify complex concepts with actual examples.
Interestingly enough, I keep skimming the text the first time and reading hate, seeing love and then reading it a second time.
Edit: At least I did it twice.
@@ChaoticNeutralMatt oh god, same here
Oh Lord
I always knew if I was lazy and waited long enough that Fireship would teach me about design patterns. 😂
Truly the best source for simplifying complex concepts.
Haha me too 🤣
Bro that's exactly my case 🤣
Not enough. I've been watching courses on design patterns for years, and still don't know them. The hardest part is to recognise when to use one, but for that you really need to know everything about them. 10 minutes won't be enough.
@@DavidSmith-ef4eh I just apply a few too. To be honest 🤣. I think am everything a programmer should not be 🤣
@@DavidSmith-ef4eh yeah you're absolutely right, but my point is in these 2 scenarios :
1) don't know what a design pattern is, neither categories of design pattern, neither the overall utility of each one
2) learn the *overall concepts* of common design patterns
In the first scenario, I don't have enough knowledge to even think about using a pattern
But in the second one, I can at least consider to implement some patterns when I code
So I think this video is perfect for people like me
EDIT: I didn't say this video is enough to *master* design patterns (it's up to the developer to learn them), but it's enough to *know* them
FINALLY
Design patterns are super interesting and it's especially helpful that this is in Typescript and JavaScript. Most articles about this use examples in Java and pointing out that some are overly complicated if you're using JavaScript is great. Thanks for making a video explaining all of these with pros and cons. 🔥🚀
🥉 Bronze
Yeah, some patterns emerging from Java were because of the OOP strictness it has and don't necessarily make sense outside of that constraint. Seeing these patterns make sense in a freeing language such as JS makes them feel right.
They feel right in JavaScript indeed!!!
@@123495734 Brother, what you have just said is "sus".
Lmao classic example of midwit soydev
Mind blown are the only two words I can think right now. I have been dabbling in understanding these design patterns for a while now but this is the simplest yet clear video I have come across for design patterns. Loved it!
This is the first thing I learned the hard way while entering in the professional world, thinking why haven't I been teach that before ! Glad to finally see it here !
They never teach you relevant shit in Uni or School.
@@imerence6290 Nah they do.
@Imerence i guess u weren't paying attention , since pretty much every CS/SE major include 1 course dedicated to System Design & Design patterns .
pattern info was very spread about internet and the main book of it is a confusing list.
@@mhcn7762 depends when you went to uni and where. In my case it didn't.
Apart from design patterns, I learnt all the cool features that come with Typescript. Thanks Jeff
Just started reading "Head First Design Patterns" today. Perfect timing.
What a coincidence me too 👀👀
Wow interesting. Do I have to purchase the book?
It would depend on how much experience you have
Is the book good? Im planning to buy one.
Great book to actually learn design patterns without falling asleep
I always thought of design patterns as something really complex, convoluted stuff that would be so hard to learn, and only for really smart people to learn. So I was kinda intimidated to start learning it. But, this video made me realize that it looks so fun, and even I could do it. Thanks for giving me the confidence and keep making these world-class, wonderful videos.
It's fun because it's he who explains it. Traditional sources are very boring to me. I would love to watch a full design patterns course from fireship
@@yovivideos Yeah, true. I would too
I think the issue is that a lot of resources makes a lot of assumptions and theoretical problems that aren't realistic, so it it's hard to apply to your problem if you don't even know where to begin, and often overblown in a lot of cases.
Design patterns are guidelines and doesn't need to be implemented 100% the same as books explain it. Books often try to cover a lot of use-cases that you may not even need to think about.
The hardest part of learning design patterns is to remember all the names.
@@dealloc Yeah, you're right. A lot of books go into details that are irrelevant in practical application. But, I guess that's why they are books, cuz it lets you go into the rabbit hole of stuff - if you want to. As you said, since these books make a lot of assumptions about your current knowledge, it makes things harder for beginners. 👍
Could you do another one about some additional patterns?
- Dependency injection
- Adapter/Translator
- Bridge/Opaque Pointer/Pimpl
- RAII
- Visitor
And maybe a separate video about concurrency patterns.
I have a BS in Computer Science from Drexel, and learned a lot of this back then, and this is a very nice overview/refresher. I can tell you that at least in my career, I've rarely worked with engineers who think and talk about code and problems they're solving in these types of terms. A lot of time, explicit choices of pattern usage comes after the fact, if at all. Sometimes the hardest part is identifying when a pattern is in use, especially if it spans multiple files and/or directories. Even as a senior engineer or architect, I struggle with that. It really does require a shift in mindset (both individual and the team you work on), that touches not just on when you're typing out the code, but when you're planning or refining the work that needs to be done. Teams which can talk about these things ahead of time and document it in their ticketing system will have a much easier time when it comes to code review and pull requests, and QA engineers will have an easier time following along and identifying/pointing out potential areas of incorrectness when bugs are encountered. And for the sake of junior engineers, or engineers who've never taken a course on design patterns, document in the code itself when a particular pattern is being used. A link to the e-book, or at least the name of the book/place/blog/whatever where it originated can save everyone time and energy.
I disagree, these patterns are either built-in to modern languages, common sense, or a bad idea.
It's super interesting when you learn Design patterns really late in your CS Career. You realize that you already implemented some of those patterns without knowing it or you already met a problem that would have been solved with one of those patterns
The way you describe this stuff is so pragmatic. As much as I appreciate everyone's work on educational content, on here, this type of pragmatic approach is exactly what is missing from the majority of videos on these topics.
This guy has the ability to read viewer's minds!!!!
Content like this, code reports and 100 seconds make this literally the best channel ive seen in many years. Been here even before you had 1 million subscribers and let me say you deserve 10 millions subs!!!
I’m just starting out in programming and this is the kind of thing I’m looking for. This seems WAY more essential to coding than learning the syntax. Yeah you need to know how your tools work and its better and faster to know the right tool but if you don’t know how to build the house it really doesn’t matter.
No, it's actually all either common sense or outdated.
Funny thing how I have used some of these patterns over the years but under different names:
- Singleton: static / global class
- Builder: classic object definition from C++
- Factory: I used to refer to this as "builder" and many of my older codes named factories as "builder"
- Facade: encapsulation
- Proxy: wrapper
- Observer: event listener
- Mediator: router
My all-time favorite is "Composite pattern" used especially in GUIs.
thats a confusing name though. It should be called grouping pattern... I've never found an application for it honesty.
@David Smith Well, I think HTML is a good example of Composite pattern. When a browser wants to calculate size of an element (like 'div') in page, it does not matter whether that 'div' is a container of more elements or if it contains no child elements. The browser treats a "container div" and a "non-container div" the same way.
@@mahdihosseinzadeh sure, folder/file system is another example. But I never used the pattern my self.
In videogames is usted a lot. Unity and Unreal Engine is structured that way.
Why? For example there can be enemies that walk, fly, hit or shoot, and allies that can also walk, fly, hit or shoot.
If you want to implement those features only once and not end with a god class, you cannot do it with just inheritance, because there is not a clear hierarchy.
One good way to do it is by creating a "gameobject" that can have components, and then create the walk, fly, hit, shoot, and behavioral components (and the behavioral component would delegate the enemy or ally using composition)
you deserve 2 trophies, one for condensing all this content in 10 minutes with this level of clarity (might be biased since I already knew about these design patterns), and the second one just in case you lose the first one.
Pure synchronization! I've been studying patterns for the last two weeks and some days ago I was reading through Refactoring Guru. Now you guys, one of my favorite youtube channels, made a video about it. Thanks!
I love this book, and also this video! Also that maze at 1:24 is literally unsolvable (at least from what we can see)
maybe there are tunnels :D
Plot twist: The guy is standing their since he actually finished the maze
5:01 (corruption) was a really nice touch
Usually I have tutorials on 1.5x speed, but this is so information rich I need to be on 0.75. Thank you!
It's really hard to make examples that are complex enough that it makes sense to use the feature being taught, but simple enough to understand quickly. You nail it every time.
Thanks Jeff for this value-packed content. Once you understand the value of these design patterns, it is hard to go back to the Play-Doh snakes. Even in my tutorials, sometimes I know that writing Play-doh snakes will be faster and easier for beginners to understand, but I still can't help myself from not spending extra 15-30 minutes to implement everything based on best practices. It's important to get started with the right foot.
That’s one of your best videos thus far. I can’t imagine explaining the GoF book in 10 mins. Great job!
Such a much needed video! I feel that programmers today gloss over these fundamental software design patterns because they are already given features that solve them out of the box with high level languages. And so many never learn why those features exist and are still prone to recreating basic design flaws in code.
And the issue with giving them a textbook like Design Patterns by gang of four is that although the concepts are timeless and fundamental, the terminology is outdated and many of the patterns in the book are eased in higher languages with powerful language-native abstractions
So there’s a discrepancy where for newer programmers the patterns need to be translated into modern terminology and shown what modern language features correspond to which patterns!
Wow, I finally understand the design patterns I took in college. I am interested now in reading more about them and using them in my future projects.
The best thing I loved about this video that not all patterns are required for language like JavaScript due to the nature of them
Awesome video, even after 10 years of programming we can still learn a lot from the basics, thank you for that video
For anyone confused as I was for a long time...
The factory example in the video is not the design pattern called Factory Method (Virtual Constructor).
The book talks about a Template Pattern that behaves different, like a factory.
The name factory can be associated with a class that creates another class, making even the Builder Pattern a factory.
The difference of the Smple Factory (the one showed in the video) with the design pattern is the Open Closed Principle. The Factory Method does not break the principle but Simple Factory does.
Sorry for the long comment, I recently learned the difference and thought it was good to share
At 2:05 In JS, objects aren’t passed by reference. Their reference ID is copied into a new value and that is passed. That’s why you can update properties but not the entire object. Small but important distinction
I am an indie game developer, I think that the builder pattern works great for all the objects, the mediator is great for inputs and controlling objects, the state is good for controlling the game flow, but like you said, it works on step bases and its very easy to mess.
Simpler iterator pattern using generator functions:
function* range(from, to, step = 1) {
for(let i = from; i < to; i += step) {
yield i;
}
}
Or you know... you can just use for loop directly. :)
I think the he implemented the iterator method to work with of.
@@luizAugustoll generator function does work with for-of loop
You can even use a generator for the iterator implementation to make the range function an iterable. It's the perfect use case for a generator!
const range = (start, end, step = 1) => ({
*[Symbol.iterator]() {
for (let i = start; i
I'm just starting with programming and just when I think I know what I need to know, you show me something new to learn. Thank alot man you are teaching literally more than half of what I know.
Thank for the quality content. My professor just give me introduction to design pattern today. Your video is very helpful.
I'd love to see another video covering more design patterns.
As a new programmer this makes me feel like I'm not completely lost on at sea on if what I'm doing is a good way to design my code instead of just randomly doing the first idea that pops in my head or contemplating it for hours without getting anything done.
Singletons are useful for logging & error reporting. ActionPack, an important piece of rails, uses Singletons for route deprecation and Mime type identification. Sprinkling Singleton spice over a codebase would suck probably, but they aren't useless.
They are a colossal pita to test (to test an object you may need a fresh copy of the object many times) and so not recommended at a few minor places like google ..
I like the bold name for a simple global object
Very interesting, I've been programming for around 10 years now and just now am learning the names of these patterns I've been using for years haha.
The only one that was completely new was the prototype pattern, I come from a mostly java reverse engineering background so I've always thought of that kind of like proxies.
I literally just did a class presentation about Software Design Patterns. You are a mind reader
Same, but last semester. I almost failed that class because we had to memorise every design pattern out there which was absolute hell.
The facade pattern is extremely underrated. It does way more than just abstract away complex logic. Its real super power is to make your code more testable with dependency injection.
One important thing to remember is that design patterns are not all or nothing. Each of the patterns are often used together, and some are just specialized versions of more fundamental patterns. A bit like how all multiples of 4 are also multiples of 2.
19th! New PB, woop! But seriously, very concise explanation and would love to hear a 100 seconds on each pattern to go to the next level.
Do you have superpower to read viewers mind, I was just thinking about learning design patterns. Thanks a lot for comprehensive video.
;)
Next video : Telepathy in 100 seconds xD
Holy shit this is EXACTLY what I need, this is like my personal bleeding edge of "technologies" regarding programming, that I am just about to learn, right when I actually run into problems that are solved by some of these design philosophies
To keep it simple: Awesome video :D
For anyone questioning their knowledge: The builder pattern as explained in this video is wrong.
Can you elaborate please?
How so ? can you please explain.
@@tropicaldog430 He just added setters which can be chained. With the builder pattern, you have a dedicated builder class with these setters. In the end, you call build() and receive the object you wanted, usually immutable.
The state pattern he describes is also just the strategy pattern
@@31redorange08 like StringBuilder?
Shout out to Refactoring Guru. It really helps me understand the design pattern more clearly!
Generally I don't like when youtubers ask for a subscription, but this was well done!
(8:40)
Yesterday I discovered design patterns in programming. I thought I'll look into it further and today this is the first video on my youtube. The universe sometimes listen to you
You mean you googled somwthing about that or discvussed it near your phone? That is just google listening, not the univer xD
@@delanmorstik7619 I disagree. Google can listen to me but a creator can't make a video about it right away.
I love your videos, but the builder pattern as shown here is very different from the common interpretation of it. The point of the builder pattern is to separate the representation of an object from its construction process. This involves separating it into two classes, ie, Car, and CarBuilder. You create a CarBuilder, and use its methods, typically chained, which eventually give you a Car. This pattern is very common in Java and C# but also seen in other languages like C/C++ and Rust.
Of course, this pattern is uncommon in JS where the most popular way to create an object is to pass an init/config object to a constructor or factory method, thanks to the object literal syntax.
Things are interchangeable, you could also create a config/init object in those other languages and remove the builder pattern. It’s just a little more verbose than js but is totally okay.
You can also use the functional options pattern to create objects. They are so much way of creating objects 😅
Isn't that thing showed in video called fluent interface?
I use most of these without even knowing their names. Thank you for the video. It amazing
Just yesterday I searched for design patterns for the first time and also stumbled across Refactoring Guru. Are you spying on my work laptop? Not complaining! Thanks for delivering this video just when I needed it. :D
Liked the examples. Observer pattern example is good.
That's because it's the most like functional programming. The application state is kept sacred.
Amazing video. Love the quick, straightforward, clear, honest and self-humorous explanations. :-)
Great video, although I low-key expected some manner of criticism given how easy it is to overuse these patterns. What often happens is that people use these so frequently that rather than genuinely trying to provide a solution to a problem, they try to re-shape the problem in a way that there is an obvious cookie-cutter solution to it. That is of course not the problem of the patterns themselves, so I understand that you make no mention of this. Giving some examples of when _not_ to use GOF patterns would be immensely helpful though, in a future video perhaps?
Excellent. I like the mix of diagrams with simple code block examples. Beyond me, but videos like this will get me there. Thanks.
This guy is Eminem of programming
You nailed it at 1:22. Overused, too much boilerplate, gotta open 7 new tabs to even see what’s happening.
It’s really just gatekeeping. Like, “they can’t replace me, nobody will ever figure out my genius design pattern”
Spaghetti 🍝 design is still the most common. Whole internet is relying on it. It is like PHP among patterns.
Excellent video. Definitely the best explanation of avoiding switch /case hell out there. A great reason I read about why you should use the factory pattern in JS ( even when it's as simple as function taking a Class returning new Class), is because making changes from that point onwards just involves altering the function, i.e. in one place. But changing every "new Class" instantiation to a factory can be a huge a breaking change.
Dude you lost me at TS!!
Tough sh!t 😬
For real! He could have used any language that heavily promotes oop like java
@@arisu_devTypeScript is expressive enough to illustrate the patterns while Java is too verbose and makes it too codey
LOVE IT! Thanks for this video Fireship!
They're based in Ukraine 😥☹️ sorry guys hope you survive..what are the odds of not loosing staff😭 impossible
I'm a copy/paste warrior and after looking at their site, I'm definitely a "Template"-type design user. I'm not so creative on my own, but I'm usually pretty good at having code up in one window and then completely rewriting it to be better on a second window.
Despite the economic downturn, I have been earning $50,000 returns from my $10,000 investment every 14 days.
Same here, I make $32,400 profits on my investment since I started trading with Expert Christine Norine Martin, her trading strategies are top notch. I’m winning consistently trading with Mrs Christine. She’s really the best broker. I've made a lot of profit investing with her.
I’ve heard a lot about investments with Mrs Christine Martin and how good she is, please how safe are the profits?
On what’ spp⤵️
꧂‿十𝟏𝟕𝟒𝟕𝟐𝟔𝟑𝟐𝟏𝟎𝟖‿꧁🇺🇸
I made $13,542 with Mrs Christine after my 10 business days of trading and I got my profit directly sent to my wallet. Good woman ♥️
You know what's crazy? I searched for like 2 hours yesterday for design pattern videos. And then, here you are.
I hate when people talk fast on purpose not letting the other follow their reasoning, so that they feel smarter
Your English just sucks
Thanks for covering my subject , and fun fact we have same book as our main book for reference, and you did it in 10 min , hats off to you
First
🥇 Gold!
Found your channel a few days ago man, I've been binge watching your videos since. Amazing content much love from a software engineer !
Hey, great video !
For the iterator pattern, you can also use a generator function (*function) and the yield keyword, like this :
// the * is essential
*[Symbol.iterator]() {
for(let i = start ; i != stop ; i+=step) {
yield i;
}
}
Feel free to check on MDN how generator functions work, it's pretty interesting :)
Exactly what I was thinking
Just like in python
Good call, generators are on my video idea list
oh shit, big 🧠
@@Fireship Glad to ear this !
Keep it up, your videos are awesome :)
This is like one of the best videos you've done so far
I always find it amazing how you can talk for 11 minutes and 3 seconds without ever breathing. I have to say it makes following along harder than it needs to be (I think it's ok if you're videos are a bit longer: the power of the pause in public speaking)
🤯We need a part 2 and possibly a dependency injection vid to boot!
You need to do a video on how you select your video topics. You are like the perfect algorithm. Every video is slam dunk
this time im the guy who can say perfect timing. started in the morning to refresh my knowledge and now your video. very nice
Man, this was brain-opening! Cool to be understanding such complex topics thanks to Fireship's skillful explanations
This video (like many Fireship ones) is simply MASTERFUL ♥️ ! Thank you so much for making
Thanks you for talking about language specific features related to design patterns. This is what many websites are missing.
🔥 video! Probably the best video on the topic I’ve seen
Thanks very much. I am very much a "noob" at programming and am cursed with knowing a little of a lot of those examples and so find it difficult to get my head into a fixed pattern of writing codes.
After watching that I take some solace knowing this is common.
On a higher level I get what you are saying, and your examples are good, but my brain goes into overload as I am not familiar with the terms used and you are going at it fairly fast.
(luckily I can "rewind" and watch things again and again.
4:57 "A facade is the face of a building. Inside that building there's all kinds of shenanigans, corruption, and complexity that the user doesn't need to know about."
OMG, I almost fell out of my chair with that one.
This is like British humor++.
Holy guac, you sped through my past 2 years of development in 11 minutes.
Great overview of common vocabulary for describing recurring patterns in programming!
Singleton: This is a creational pattern that allows creating only one instance of a class throughout the application. This pattern is useful when we want to limit the number of instances of a particular class in the program.
Prototype: This pattern involves creating a new object based on an existing object, also known as cloning. This pattern is useful when we need to create many objects with similar attributes or functionality.
Builder: This is another creational pattern that separates the construction of a complex object from its representation. This pattern is useful when we need to create an object that requires several steps to be constructed.
Factory: This pattern involves creating objects without specifying the exact class of the object that will be created. This pattern is useful when we need to create objects based on a certain condition or logic.
Facade: This is a structural pattern that provides a simple interface to a complex system of classes. This pattern is useful when we want to simplify the use of a complex system by providing a high-level interface.
Proxy: This pattern involves creating a placeholder object that represents another object. This pattern is useful when we want to control the access to an object, add extra functionality
Iterator Pattern: The Iterator Pattern provides a way to access the elements of an object sequentially without exposing its underlying representation. It defines an object that encapsulates the collection of elements and an interface for accessing them one by one in a specific order.
Observer Pattern: The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. It provides a way for objects to communicate and stay in sync with each other.
Mediator Pattern: The Mediator Pattern defines an object that encapsulates how a set of objects interact with each other. It promotes loose coupling by keeping objects from referring to each other explicitly and allows them to communicate through the mediator.
State Pattern: The State Pattern allows an object to alter its behavior when its internal state changes. It encapsulates state-specific behavior into separate classes and delegates to the object representing the current state to handle requests.
One of the best videos you've ever made. Feel free to make a part 2 should you find yourself with too much free time on your hands 🙃
I think you are King. I have saved days of learning "design patterns" by watching this video.
refactoring guru for the win, their explanation of design patterns are great
These things are so important to know!
Even if you don't use any of this, sometimes u can use patterns like this in a smaller way or solve another problem better just because u know whats possible
This is the best video 🔥🔥🔥 I have watched explaining design patterns in an elegant way. Thanks
I love videos like this. The theory is the important part of being a developer.
The repository pattern is awesome!
I love the edition of your videos! Good content, and high quality as well.
I have read some, but I'm glad now I get better understanding of it, thanks to you teaching skills
My favorite design patterns are ones that solve development problems. If you use VS Code for vanilla JS like me, you'll notice code hinting falls apart sometimes when passing a custom class to a function, thus changing the scope. One trick I use is class constructors with a self-creation clause at the beginning: constructor(input) { if (input instanceof ClassName) return input; }-This allows you to "cast" a variable as that class by using myVar = new ClassName(myVar); which seems unnecessary because it doesn't actually do anything but it's enough to let VS Code know what class that variable has since you don't have typed parameters in JS, thus fixing the issue of missing code hints. Microsoft could probably fix this issue with a more robust JS engine but it's fun finding work-arounds to common problems nonetheless.
Either I am too lucky or Jeff knows what's going in my mind, as yesterday I was searching for design patterns and now just saw the best explanation I think I could ever get.
Thanks for showing this! This video fell on my recommendations when I wanted to check about design patterns since I am mostly fumbling by myself with regards to programming.
This video is so dense with amazing information. I need more of this for other topics. Following.