For people, who are interested in learning the design patterns now: - use the book mentioned in the video mainly as a reference book (it's pretty good for that) - don't just learn or read about the different patterns, practice them at least in small projects, the ability to see where specific patterns might be useful in larger codebases comes only with practice, experience, and time - if you know a little java: Head First: Design Patterns, one of the best resources you can use to learn the most important ones - if you don't get a pattern instantaneously, just look for different explanations and 'tutorials' (maybe in a programming language that you know very well). different people might use different examples to explain the patterns, so you will definitely get the hang of it after investing time to research Happy coding :)
Be aware of "The 4 Stages of Learning Design Patterns" ardalis.com/the-4-stages-of-learning-design-patterns/ 1. Ignorance 2. Awakening 3. Overzealousness 4. Mastery "Stage 3: Overzealousness" is the dangerous one - implementing patterns everywhere even in "square peg in a round hole" situations. Each pattern has 13 sections: * Pattern Name and Classification * Intent * Also Known As * Motivation * Applicability * Structure * Participants * Collaborators * Consequences * Implementation * Sample Code * Known Uses * Related Patterns It's a mistake to only focus on the name and implementation related sections. It's absolutely critical to understand: * Intent - What problem does the pattern address? * Applicability - The circumstances that make the pattern a good fit. * Consequences - The *tradeoffs* and results of using the pattern. The consequences could highlight tradeoffs that are a showstopper for some solutions. In that case "Related Patterns" may suggest alternatives that could be a better fit. The other issue is that many people treat patterns as "recipes". Patterns are more than that. The pattern names establish a common nomenclature to make technical communication more effective. For example when the term "observer pattern" appears in an article, talk or conversation the "why, what, and how" of the approach should be understood by the participants without having to get into the nitty-gritty details. It also needs to be emphasized that the "Gang of Four" patterns largely target "class-based object-oriented" implementations. Different paradigms tend to have different patterns. For some introductory functional design patterns have a look at "Functional Design Patterns - Scott Wlaschin (2017)" ruclips.net/video/srQt1NAHYC0/видео.html Occasionally there is some conceptual overlap, e.g. the Strategy pattern with higher order functions: * Context - the higher order function * Strategy - the signature of the function parameter accepted by the higher order function. * ConcreteStrategy - the function that is passed to the higher order function as a parameter. Idioms vs. design patterns. Design patterns address general structural principles. Idioms represent low-level patterns that solve implementation-specific problems in a particular programming language (Pattern-Oriented Software Architecture Vol.1).
The other thing that can be instructive when learning a design pattern is discovering how SOLID design principles are reflected in the implementation of the pattern. The GoF Book was published in 1994, SOLID was formulated in 2000 though some of the principles were identified earlier. It's just important to remember that the SOLID design principles are simply guiding principles - not laws. Developers new to SOLID often treat them as hard and fast rules to the point of dogma. That is not how they are supposed to be used. "The SOLID Design Principles Deconstructed (2013)" ruclips.net/video/tMW08JkFrBA/видео.html It needs to be emphasized that the "Single Responsibility Principle" is often interpreted as "do one thing" - which is a gross oversimplification. The actual description is: "Gather together those things that change for the same reason, and separate those things that change for different reasons." github.com/97-things/97-things-every-programmer-should-know/blob/master/en/thing_76/README.md "change for the same reason" is very different from "do one thing". Similarly DRY (Don't Repeat Yourself) is often misrepresented as being about "eliminating duplication". The core idea is described by: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". Sometimes things just _look_ the same without representing the same thing. If they have different reasons for changing they are not the same - even if they look duplicated right now.
It may be not really hard to understand those patterns, but the implementation is. I am considering to implement several of those patterns in my web app. But javascript (ES2015 or later) or typescript doesn't provide way to create abstract classes like in the examples of the book. The 1st pattern which comes to my mind is Builder (not covered here) for generating reports which varies depending on client characteristics and other conditionals. The 2nd one is Adapter. I will see whether I will need facade, factory method or not.
I've been using design patterns since only recently. I found throughout the years, many design patterns already naturally started appearing in the code I write, because it's just a sensible thing to do.
Same thing that I noticed too! I think that design patterns are just good coding practices for specific situations that have been documented since these situations are very often encountered.
Best book ever for design patterns, solid advice. I would add the factory pattern, decorator, and command too, I think those 3 are key to understand and design better solutions. Long life to Design Patterns! Thanks Brad and Jack for sharing!
talking about fundamentals, yes. The truth is every situation has its own type of best maintainable and readable solution. What you'll see is that people will merge different design patterns together while a more specialised, lesser known pattern is already available. So if you talk about practicality, its still better to learn all of the common 150 or so patterns. Note: I'm not exclusively talking about software patterns here. Learn of the reverse too: anti-patterns. They're indicators of bad pattern implementation which practically always is going to cost somebody time and effort that could have been avoided.
Design patterns make tough problems easy and impossible problems tough. Essential for gaining expertise in your field. A game developer *must* know common design patterns as well as be able to formalize new ones for the problems at hand
4 года назад+182
Singleton is an anti-pattern in most cases- definitely should not be used for datastore- we don't want global connections! Normally, the kind of singletons we use these days is using IoC container- global lifetime objects (lifetime=Singleton) Bridge and adapter are two completely different things. When the guy talks about the bridge, he actually talks about the adapter. Adapter adapts a 3rd party interface into your own system. Bridge separates the abstraction from implementation allowing you to have both changing independently. There are two very different problems being solved there. Adapter is very commonly used, Bridge is quite rare. Also, the adapter is absolutely not implemented that way: you wrap a FOREIGN component (interface or class) under YOUR class which supports YOUR interface. That's the whole point of it- through that, we can make foreign API conform to our own abstractions. Simply having multiple implementations of the same is not an Adapter pattern. Facade is good, though it often comes out naturally when you apply common sense. Same for Strategy pattern. Observer is awesome, true. Many many applications and implementations, though at the core it simply is: subject and observer. The subject can: attach, detach and notify; the observer can react to notifications.
@Dark of the knight That's the only reason to use singleton; utilities that don't keep information inside the utility after the operation finished. Think of C# Math static class for example. In any other case, you simply design the object as if they can be instantiated multiple times, but only make one single instance that is globally available within the project. If you use singleton properly, you'll only have utility classes in the global space with just one domain class. Any other domains are separated by interfaces and usually located in other libraries or modules.
There was a nice explanation why singleton is an anti-pattern. I don't remember where I read it, but it stuck with me. What follows is not quite a quote! "Back then we wanted to avoid duplicating state through multiple instances. Today we avoid having state, so we don't need this anymore. Back then we wanted to avoid building the same object twice, today we avoid expensive constructions, so we don't need this anymore. Singleton is an anti-pattern, because it leads you down a path you don't wish to follow. If you find yourself needing it, you probably took a wrong turn already."
4 года назад+1
@Dark of the knight just because you use it often, doesn't mean it's the best choice. Also, I had no Web-based stuff in mind, no idea what are you on about. Singletons are bad for the same reason why global state is bad. It is global, but supports OOP features like abstraction.
4 года назад+5
@@msc8382 static!=Singleton. Singleton will initialize state a globally accessible state. That's the only reasons it's there. Do we want that? Sometimes, yes. Fir example app config will only be one, scene scene transition manager in games will be one, etc.
also singletone is bad if you are using it in concurrent app. You would need to handle race condition and all that stuff. But in single-threaded languages like js it's pretty useful in some cases.
Hi Jack. Great video, thank you. I'd mention that the difference between Bridge and Adapter is that Adapter is about interfaces. You adapt from the interface you get (say lines) to the interface you need (say points). While the Bridge is about components. Bridge is connecting components together through abstractions. Your explanation of the Bridge design pattern is absolutely correct and beautiful, I am just reacting to your phrase with which you started the bridge part - you said that you'd call it adapter. Thanks again for making this video.
Thanks Jack! I have been reading the simplified version of the books you recommended (head first into design pattern). I am sort of overwhelmed by all the design patterns introduced in there and I have a hard time retaining it. This video has provided me with a good summary and it helps me prioritize which ones I should spend more time on. Thanks!
There's a reason most beginners don't know design patterns: they're not a beginner-level concept. The chart near the start of the video (1:25) kind of illustrates this.
the same here I just started learning about design patterns and as you said we learn how to write code but as developers, we need to learn how to write good software.
@@voltydequa845 in the simplest way I can think to explain it (I only have 2 years experience), writing code is making something work. Writing software is taking into account the future, the current architecture, the maintenance costs of the code (which can be very expensive) and many more factors in addition to it working.
thanks Brad! i literary know anything when i first started to read this book he mentioned and i had a whole video attached to it yet find it very difficult but now i just end up here listening to the tutor i am amazed. I can now go on and do my designs .
I was goi8ng to say, "Thanks, Conan O'Brien's dad," but it seems I'm not the first to make that connection. In all seriousness, though, this was an absolutely fantastic video. You do a fantastic job of explaining these design patterns in a way that really helps to conceptualize and understand them. Thank you!
I read the title and I said “Oh yeah, he’s gonna mention MVC and let’s see what else I learn.” But instead of learning, what I got from this video was a kick from my imposter syndrome right where it hurts the most.
Best advice from this video: you can bring the patterns in later. Already decades ago, we had to add layers and layers in between source and destination so that everything would be pluggable. Which was purely hypothetical. Nothing was ever plugged in or swapped out.
"Design pattern"s by the gang of four is a classic but it is intimidating for the beginner, the example in C++ and Smalltalk doesn't help either. I prefer the more accessible "Head First Design Patterns", which is easy to read and has examples in Java.
Oh man right now I'm studying patterns, SOLID, and stuff like that and this just popped in my recommended and it was hugeeeee, really helpful, I'm grateful for this, please this guy Jack keep up the content
In the original Observer pattern the sender of an event doesn't care whether any subscriber is listening at all (typically in sync communication) (like a radio station sending at night), whereas the whole purpose of a message queue system is to ensure that the message is delivered to the "right" receiver (whatever this might be) in an async communication (like talking to an aswering machine not knowing who will listen to your message).
I can't believe I was using most of them already but didn't know they were actually patterns especially observer, singleton and facade, they are pretty handy and simple
When you described the Fascade pattern, as a javascript developer my mind went to functions. The internals of the function may be complex, but the function ideally returns one predictable type of thing. This pattern makes it easy to test your code, because you're only testing the output of the function. Later, as technology improves, you can refactor the function and do things more efficiently or more clearly, but all the rest of your code that called that function would not need to be modified. From the outside, that function still achieves the same thing. That's what I thought about when you mentioned the fascade pattern.
strategy can also be just an function, observer can be a monad, singleton can be an enviroment monad, etc. the patterns on the video are OOP patterns, made to be used with classes, interfaces and inheritance, there are also functional patterns, made to be used with higher order functions, partial applications, monads, etc.
2 года назад
Great overview of the most important patterns (in my opinion)!
One question, you mentioned one goes from a framework consumer towards a framework creator/designer; but in most jobs there is no need for yet another framework right? Is this always the case for progression?
This is incredible, thank you! Amazing how you can turn something as (seemingly) dry as design patterns into something entertaining and informative. Well done.
truth is, if you approach things logically, if you follow object oriented principles, the patterns follow through naturally. I never personally invested much time in software design patterns yet when I actually perform the design, and break things down accordingly, the patterns follow suit.
Oh it is called the pub/sub design patten. Good to know. Since I was forced to learn reactive programing (cause I needed to see how Angular 2+ works) I fell in love with it. I use it on Angular, Android Java, Flutter and on the server (BehaviorSubject) or Project Reactor. Yes sometimes an event creates indirectly more of the same even and things end up with 100% CPU.
Thanks Jack, I was looking for a brief explanation on the scope of design patterns and your examples covered it very well :D Will be checking out more of your videos!
[3:55] "patterns are actually modeled on real world building architecture" --> FALSE Read the GoF book (page 2), I'll quote:" The purpose of this book is to record experience in designing object-oriented software as design patterns. Each design pattern systematically names, explains, and evaluates an important and recurring design in object-oriented systems. Our goal isto capture design experience in a form that people can use effectively. To this end we have documented some of the most important design patterns and present them as a catalog." and (still on page 2) "None of the design patterns in this book describes new or unproven designs. We have included only designs that have been applied more than once in different systems" In short, the patterns were "found" or observered in actual software systems. It's pretty ridiculous to think that a "factory" "observer" "singleton" "strategy", or pretty much any behavioral pattern, would be inspired by building architecture. I recommend actually reading the GoF book before posting a video about what is written in the book.
my favourite pattern is probably Memento with performance optimizations. it allows me to exercise my skills on many different data structure algorithms.
Aside from the mentioned patterns, I encountered the factory and builder patterns many times. Also the pointer-to-implementation. Not all of these patterns are so critical nowadays in modern languages, but I still think the good programmer should know about them.
The camera lens was a really nice metaphor for the Adapter pattern. I always had a cable adapter in mind, which admitteldy does still explain the gist of it. But doesn't quite convey the risk of overdoing it at unneeded parts of the program. Was there a distinction in the GOF book between this and the Bridge pattern? Because I vaguely remember the Bridge doing something else.
Off topic : Is UML still needed other than for communicating our design ? I feel I need to learn Software Architecture too, including its patterns : layered, microservices, etc. I don't know whether I will have a plenty of time to read books on it, including SOA.
I'm very wary of singletons that are defined by a business requirement (e.g. we will only ever connect to one payment system, etc.) Singletons for technical reasons (e.g. this is the Singleton for talking to this micro-service) are usually ok.
Bridge and Adapter patterns are two different things. Bridges are usually written up front and Adapter's are usually written as an afterthought. A good Bridge analogy is like front-end/back-end paradigm. AJAX is the Bridge pattern between the two. Or OS API/GUI the graphics driver is the Bridge.
The bridge pattern is meant to decouple an object's abstraction from its implementation using subtyping, allowing either side of the coupling to be updated or interchanged separately. It doesn't just connect two technologies together. Ajax is not an example of Bridge. A Bridge example would be: imagine having a data model object that accesses a database, but you want to be able to swap out the database and the data model independently. The Bridge pattern is to define an interface for the database and an abstract class (or interface, depending on language) for the data model object and use those as the basis for your objects. So you might define an interface Database with methods such as find(), save(), and so on. You then define an abstract class DataModel which takes an object of type Database as a property. Now you can have interchangeable DataModel objects like a Customer, Product, SalesOrder, and so on, and you know that the Database methods find() and save() will always be available regardless of what database you use because those methods were defined on the Database interface. Adapters, by the way, aren't written as afterthoughts. In fact, they have an important use in this example. I can create a wrapper class (which is all an Adapter really is) that implements Database, encapsulate my database driver, and then map the interface's find() and save() method to whatever the equivalent driver methods are. Now I can have a MySQLAdapter, MongoDBAdapter, OracleAdapter, or any other database implementation of type Database and will be able to use them interchangeably with my DataModel objects without fuss.
A very nice presentation and thank you. I hope you don't mind if I share some of my thoughts. Design pattern implementation are just generified implementations of observable/repeatable behavior? And isn't that where their implementations become a problem, specifically when performance enters the equation? We can make almost anything generic but we can't always make them generic and performant. In the end one has to decide, code specifically to the problem or code generically around the problem.
I think you misunderstand what design patterns are. A design pattern is really just a solution to a problem. The patterns in the book come from the authors identifying the best ways they have solved the specific problems addressed in the book. The patterns themselves are ideas (techniques) and not specific implementations, therefore the performance of the code implementing the pattern is subject to the skills and understanding of the coder, not the pattern. As an analogy, a dovetail joint in carpentry/joinery is a proven technique for joining two boards together quite strongly. However, if I'm not a very skilled carpenter my dovetail joints may not work very well. Likewise, an excellent carpenter that could make the tightest dovetails with nothing but a chisel would still likely never use dovetail joints when framing walls.
This is what I was looking for. I don't want to be a framework consumer anymore. I want to build my own frameworks. Even if there is no reason for another framework, I'll build it. Coding projects for end-users for 3 years kinda cumbersome, though this job gives me money. I want to build something that might be a useful for other programmers.
I like your clean and simple descriptions of pros and cons and I especially liked your touching on refactoring code from one pattern to another....I feel that micro-services are an embodyment of observer/Pub-sub and soo may eliminate the need to hard code the logic of the pattern....my own view is evolving to imutable (where possible) event stream workflow sagas of micro-services in containers. I like the use of UML in visualizing/creating patterns (and anti-patterns).
Thanks again Brad for hosting my video on your channel. It's great that you are giving creators this opportunity.
Thanks for letting me, Great stuff!
Spreading the word of GoF, thanks Jack!
Brad, can we see unit testing (maybe even TDD) in React soon?
Superb info
It's a very useful and important video. Thanks to both of you 🙏🏻
Great overall guide.
1. Singleton (DB driver)
2. Facade (building front view)
3. Bridge/Connector (APIs)
4. Strategy ( notification to sales clients)
5. Pub-Sub/Observer (event based)
cool
thanks for your summary
thanks
For people, who are interested in learning the design patterns now:
- use the book mentioned in the video mainly as a reference book (it's pretty good for that)
- don't just learn or read about the different patterns, practice them at least in small projects, the ability to see where specific patterns might be useful in larger codebases comes only with practice, experience, and time
- if you know a little java: Head First: Design Patterns, one of the best resources you can use to learn the most important ones
- if you don't get a pattern instantaneously, just look for different explanations and 'tutorials' (maybe in a programming language that you know very well). different people might use different examples to explain the patterns, so you will definitely get the hang of it after investing time to research
Happy coding :)
thank you for this comment
Be aware of "The 4 Stages of Learning Design Patterns"
ardalis.com/the-4-stages-of-learning-design-patterns/
1. Ignorance
2. Awakening
3. Overzealousness
4. Mastery
"Stage 3: Overzealousness" is the dangerous one - implementing patterns everywhere even in "square peg in a round hole" situations.
Each pattern has 13 sections:
* Pattern Name and Classification
* Intent
* Also Known As
* Motivation
* Applicability
* Structure
* Participants
* Collaborators
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns
It's a mistake to only focus on the name and implementation related sections. It's absolutely critical to understand:
* Intent - What problem does the pattern address?
* Applicability - The circumstances that make the pattern a good fit.
* Consequences - The *tradeoffs* and results of using the pattern.
The consequences could highlight tradeoffs that are a showstopper for some solutions. In that case "Related Patterns" may suggest alternatives that could be a better fit.
The other issue is that many people treat patterns as "recipes". Patterns are more than that.
The pattern names establish a common nomenclature to make technical communication more effective. For example when the term "observer pattern" appears in an article, talk or conversation the "why, what, and how" of the approach should be understood by the participants without having to get into the nitty-gritty details.
It also needs to be emphasized that the "Gang of Four" patterns largely target "class-based object-oriented" implementations. Different paradigms tend to have different patterns.
For some introductory functional design patterns have a look at "Functional Design Patterns - Scott Wlaschin (2017)"
ruclips.net/video/srQt1NAHYC0/видео.html
Occasionally there is some conceptual overlap, e.g. the Strategy pattern with higher order functions:
* Context - the higher order function
* Strategy - the signature of the function parameter accepted by the higher order function.
* ConcreteStrategy - the function that is passed to the higher order function as a parameter.
Idioms vs. design patterns. Design patterns address general structural principles. Idioms represent low-level patterns that solve implementation-specific problems in a particular programming language (Pattern-Oriented Software Architecture Vol.1).
Also, patterns are not mandatory. Don't try to force a pattern implementation
The other thing that can be instructive when learning a design pattern is discovering how SOLID design principles are reflected in the implementation of the pattern.
The GoF Book was published in 1994, SOLID was formulated in 2000 though some of the principles were identified earlier.
It's just important to remember that the SOLID design principles are simply guiding principles - not laws. Developers new to SOLID often treat them as hard and fast rules to the point of dogma. That is not how they are supposed to be used.
"The SOLID Design Principles Deconstructed (2013)"
ruclips.net/video/tMW08JkFrBA/видео.html
It needs to be emphasized that the "Single Responsibility Principle" is often interpreted as "do one thing" - which is a gross oversimplification. The actual description is:
"Gather together those things that change for the same reason, and separate those things that change for different reasons."
github.com/97-things/97-things-every-programmer-should-know/blob/master/en/thing_76/README.md
"change for the same reason" is very different from "do one thing".
Similarly DRY (Don't Repeat Yourself) is often misrepresented as being about "eliminating duplication". The core idea is described by:
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system".
Sometimes things just _look_ the same without representing the same thing. If they have different reasons for changing they are not the same - even if they look duplicated right now.
It may be not really hard to understand those patterns, but the implementation is. I am considering to implement several of those patterns in my web app. But javascript (ES2015 or later) or typescript doesn't provide way to create abstract classes like in the examples of the book.
The 1st pattern which comes to my mind is Builder (not covered here) for generating reports which varies depending on client characteristics and other conditionals. The 2nd one is Adapter. I will see whether I will need facade, factory method or not.
2:14 Singleton Pattern
3:50 Facade Pattern
5:47 Bridge/Adapter Pattern
8:02 Strategy Pattern
9:48 Observer Pattern (PubSub)
The timestamps are already in the description.
And already divided into chapters
@@MrNsaysHi 00 Z yi
what a sad comment, isn't it?
I've been using design patterns since only recently. I found throughout the years, many design patterns already naturally started appearing in the code I write, because it's just a sensible thing to do.
Same thing that I noticed too!
I think that design patterns are just good coding practices for specific situations that have been documented since these situations are very often encountered.
Who knew that Conan O'Brien is a coder? Fascinating.
😂😂not me.....and yes they look the same
Gold
Hmmteresting
If Conan and Chris Hansen fused
😂 👌.... Lil chubby tho.
Best book ever for design patterns, solid advice.
I would add the factory pattern, decorator, and command too, I think those 3 are key to understand and design better solutions.
Long life to Design Patterns!
Thanks Brad and Jack for sharing!
talking about fundamentals, yes.
The truth is every situation has its own type of best maintainable and readable solution.
What you'll see is that people will merge different design patterns together while a more specialised, lesser known pattern is already available. So if you talk about practicality, its still better to learn all of the common 150 or so patterns.
Note: I'm not exclusively talking about software patterns here. Learn of the reverse too: anti-patterns. They're indicators of bad pattern implementation which practically always is going to cost somebody time and effort that could have been avoided.
Ah, I wonder what was the programming life before the era of patterning the common sense.
Design patterns make tough problems easy and impossible problems tough.
Essential for gaining expertise in your field. A game developer *must* know common design patterns as well as be able to formalize new ones for the problems at hand
Singleton is an anti-pattern in most cases- definitely should not be used for datastore- we don't want global connections! Normally, the kind of singletons we use these days is using IoC container- global lifetime objects (lifetime=Singleton)
Bridge and adapter are two completely different things. When the guy talks about the bridge, he actually talks about the adapter. Adapter adapts a 3rd party interface into your own system. Bridge separates the abstraction from implementation allowing you to have both changing independently. There are two very different problems being solved there. Adapter is very commonly used, Bridge is quite rare. Also, the adapter is absolutely not implemented that way: you wrap a FOREIGN component (interface or class) under YOUR class which supports YOUR interface. That's the whole point of it- through that, we can make foreign API conform to our own abstractions. Simply having multiple implementations of the same is not an Adapter pattern.
Facade is good, though it often comes out naturally when you apply common sense. Same for Strategy pattern.
Observer is awesome, true. Many many applications and implementations, though at the core it simply is: subject and observer. The subject can: attach, detach and notify; the observer can react to notifications.
@Dark of the knight That's the only reason to use singleton; utilities that don't keep information inside the utility after the operation finished. Think of C# Math static class for example.
In any other case, you simply design the object as if they can be instantiated multiple times, but only make one single instance that is globally available within the project.
If you use singleton properly, you'll only have utility classes in the global space with just one domain class. Any other domains are separated by interfaces and usually located in other libraries or modules.
There was a nice explanation why singleton is an anti-pattern. I don't remember where I read it, but it stuck with me. What follows is not quite a quote!
"Back then we wanted to avoid duplicating state through multiple instances. Today we avoid having state, so we don't need this anymore. Back then we wanted to avoid building the same object twice, today we avoid expensive constructions, so we don't need this anymore. Singleton is an anti-pattern, because it leads you down a path you don't wish to follow. If you find yourself needing it, you probably took a wrong turn already."
@Dark of the knight just because you use it often, doesn't mean it's the best choice. Also, I had no Web-based stuff in mind, no idea what are you on about. Singletons are bad for the same reason why global state is bad.
It is global, but supports OOP features like abstraction.
@@msc8382 static!=Singleton. Singleton will initialize state a globally accessible state. That's the only reasons it's there. Do we want that? Sometimes, yes. Fir example app config will only be one, scene scene transition manager in games will be one, etc.
also singletone is bad if you are using it in concurrent app. You would need to handle race condition and all that stuff. But in single-threaded languages like js it's pretty useful in some cases.
Holy cow, the first minute hits the nail on the head SO MUCH. I am "Senior" but still lame Framework consumer.
I love the way you talk about design patterns and giving fantastic examples. Thank you so much for sharing your knowledge.
Hi Jack. Great video, thank you. I'd mention that the difference between Bridge and Adapter is that Adapter is about interfaces. You adapt from the interface you get (say lines) to the interface you need (say points). While the Bridge is about components. Bridge is connecting components together through abstractions. Your explanation of the Bridge design pattern is absolutely correct and beautiful, I am just reacting to your phrase with which you started the bridge part - you said that you'd call it adapter. Thanks again for making this video.
I love the Facade Pattern. One of my other favorites not covered in the video is the factory pattern in JavaScript.
Watching this later!
Which factory; there are so many different types of factory patterns
Thanks Jack! I have been reading the simplified version of the books you recommended (head first into design pattern). I am sort of overwhelmed by all the design patterns introduced in there and I have a hard time retaining it. This video has provided me with a good summary and it helps me prioritize which ones I should spend more time on. Thanks!
Best description of the Facade pattern that I ever heard, the compiler analogy was brilliant!
I'm a simple man...I see a video by Jack, I give a like. Awesome content!
Much needed.. The thing most beginners misses
I agree. I did not even look into design patterns until maybe 2 years after I started coding
Thanks brad for the reply. Hope to see a cool series on Design patterns soon
There's a reason most beginners don't know design patterns: they're not a beginner-level concept. The chart near the start of the video (1:25) kind of illustrates this.
To be fair, programming design patterns require a certain level of proficiency to fully comprehend.
Yes you're right
Great topic! Just started studying design pattern and SOLID. Makes you understand HOW to write software vs writing code.
the same here I just started learning about design patterns and as you said we learn how to write code but as developers, we need to learn how to write good software.
And what would be the differsnce?
@@voltydequa845 in the simplest way I can think to explain it (I only have 2 years experience), writing code is making something work. Writing software is taking into account the future, the current architecture, the maintenance costs of the code (which can be very expensive) and many more factors in addition to it working.
Hey Jack, your overview on design patterns made me rethink those services that I used unconsciously at my job and thank you for the valuable insights.
2:10 Singleton Pattern
3:30 Facade Pattern
5:40 Bridge/Adapter Pattern
8:00 Strategy Pattern
9:50 Observer Pattern (PubSub)
Informative video 👍👍
"There can be only one" classic. Thanks for the video, much appreciated
Monke Flip
thanks Brad! i literary know anything when i first started to read this book he mentioned and i had a whole video attached to it yet find it very difficult but now i just end up here listening to the tutor i am amazed. I can now go on and do my designs .
I was goi8ng to say, "Thanks, Conan O'Brien's dad," but it seems I'm not the first to make that connection. In all seriousness, though, this was an absolutely fantastic video. You do a fantastic job of explaining these design patterns in a way that really helps to conceptualize and understand them. Thank you!
Stumbled across your video. Nice presentation. Thanks. Wonderful to hear about this.. Vlissides was a great guy. My friend from days gone by.
Having quit development 25 years ago and looking to jump back in, it is great to see the same book still being used.
Principles are valuable. They always have been, and they always will be.
I read the title and I said “Oh yeah, he’s gonna mention MVC and let’s see what else I learn.”
But instead of learning, what I got from this video was a kick from my imposter syndrome right where it hurts the most.
Right? It seems so obvious now...
syndrome Was The Imposter
You're a sus? Me too.
Best advice from this video: you can bring the patterns in later. Already decades ago, we had to add layers and layers in between source and destination so that everything would be pluggable. Which was purely hypothetical. Nothing was ever plugged in or swapped out.
Adapter pattern is so essential for extending software. Should def be here.
Design Patterns Series could be The Most awaited series and Most useful series for everyone besides of their stack.
I love what's going on with this channel lately. Subscribed to Jack's channel. Thanks.
One of the best tech videos I have ever seen
"Design pattern"s by the gang of four is a classic but it is intimidating for the beginner, the example in C++ and Smalltalk doesn't help either.
I prefer the more accessible "Head First Design Patterns", which is easy to read and has examples in Java.
thank you so much
Oh man right now I'm studying patterns, SOLID, and stuff like that and this just popped in my recommended and it was hugeeeee, really helpful, I'm grateful for this, please this guy Jack keep up the content
In the original Observer pattern the sender of an event doesn't care whether any subscriber is listening at all (typically in sync communication) (like a radio station sending at night), whereas the whole purpose of a message queue system is to ensure that the message is delivered to the "right" receiver (whatever this might be) in an async communication (like talking to an aswering machine not knowing who will listen to your message).
I can't believe I was using most of them already but didn't know they were actually patterns especially observer, singleton and facade, they are pretty handy and simple
Now that you know the names you are a 10x programmer!
I really enjoy your videos. I wish I was as good at following through as I am at watching them.
You are the best teacher... You are my guru now
Jack is a great guy. Thanks for sharing your knowledge and experience on the channel. Really enjoyed the video !
Love the framework consumer vs framework creator bit at the beginning!
When you described the Fascade pattern, as a javascript developer my mind went to functions. The internals of the function may be complex, but the function ideally returns one predictable type of thing. This pattern makes it easy to test your code, because you're only testing the output of the function. Later, as technology improves, you can refactor the function and do things more efficiently or more clearly, but all the rest of your code that called that function would not need to be modified. From the outside, that function still achieves the same thing. That's what I thought about when you mentioned the fascade pattern.
strategy can also be just an function, observer can be a monad, singleton can be an enviroment monad, etc. the patterns on the video are OOP patterns, made to be used with classes, interfaces and inheritance, there are also functional patterns, made to be used with higher order functions, partial applications, monads, etc.
Great overview of the most important patterns (in my opinion)!
This video is of the highest quality. Love the content. Love the production.
I didn't know Conan O' Brian was also an engineer. Brilliant!
I was looking for this comment,lol 🤣
It's nice to finally put a face to the voice of the man who has made me into the man I am today...
software architecture is harder than technical coding, glad this tutorial exists.
I can attest to each and every one of these. Good video for everyone from beginners to advanced old timers.
The world 🌎 pays much respect these men!!
I'm really loving the new direction of the channel! we get so much variety that I otherwise may not have come across or been interested in.
One question, you mentioned one goes from a framework consumer towards a framework creator/designer; but in most jobs there is no need for yet another framework right? Is this always the case for progression?
Thank you.
Love and respect 🙏 from Sikkim, India 🇮🇳.
Shut up I am from India too okay but this shows that you are one of the freaks who write "love from India
This is incredible, thank you! Amazing how you can turn something as (seemingly) dry as design patterns into something entertaining and informative. Well done.
High quality content, loving it! Got my like when you whipped out that old book!
Factory pattern and Builder pattern are two other ones that I think are also very useful.
truth is, if you approach things logically, if you follow object oriented principles, the patterns follow through naturally. I never personally invested much time in software design patterns yet when I actually perform the design, and break things down accordingly, the patterns follow suit.
Oh it is called the pub/sub design patten. Good to know. Since I was forced to learn reactive programing (cause I needed to see how Angular 2+ works) I fell in love with it.
I use it on Angular, Android Java, Flutter and on the server (BehaviorSubject) or Project Reactor.
Yes sometimes an event creates indirectly more of the same even and things end up with 100% CPU.
Excellent video, thanks a bunch, greetings from Mexico - Oaxaca
This man sounds so elegant, which is a particularly rare quality for stereotypical coders.
Thanks Jack, I was looking for a brief explanation on the scope of design patterns and your examples covered it very well :D Will be checking out more of your videos!
I would strongly recommend the MV* pattern as well for any non-trivial web development (can be extended to toher use cases as well)
Loved it. Must watch for all devs. Thanks for this Jack. Thanks again, brad.
@Jack Herrington Isn't the "Strategy" pattern better suited to be a called a microservices architectural approach ?
4:36 Does Senior need to know how to code a compiler ? artichec ?
Thank you, i finally understand Singleton and it was so straightforward.
10:20 I remember experimenting with the Observer Pattern and exactly this happened to me. I felt that in my soul.
4:10 abstraction. I heard it explained as pressing a gas pedal in the car and it going forward without needing to know all the moving parts.
Thanks Brad,
Thanks Jack for sharing the information
[3:55] "patterns are actually modeled on real world building architecture" --> FALSE
Read the GoF book (page 2), I'll quote:"
The purpose of this book is to record experience in designing object-oriented software as
design patterns. Each design pattern systematically names, explains, and evaluates an
important and recurring design in object-oriented systems. Our goal isto capture design
experience in a form that people can use effectively. To this end we have documented
some of the most important design patterns and present them as a catalog."
and (still on page 2)
"None of the design patterns in this book describes new or unproven designs. We have
included only designs that have been applied more than once in different systems"
In short, the patterns were "found" or observered in actual software systems.
It's pretty ridiculous to think that a "factory" "observer" "singleton" "strategy", or pretty much any behavioral pattern, would be inspired by building architecture.
I recommend actually reading the GoF book before posting a video about what is written in the book.
thanks brad and your videos are awesome!👌
Very surprised that the Factory pattern in not on the list. The Command pattern is very cool too.
It was a tough call. Had to pick five. But Factory would have been in there if I'd done more.
my favourite pattern is probably Memento with performance optimizations. it allows me to exercise my skills on many different data structure algorithms.
Aside from the mentioned patterns, I encountered the factory and builder patterns many times.
Also the pointer-to-implementation.
Not all of these patterns are so critical nowadays in modern languages, but I still think the good programmer should know about them.
A good programmer has a creative phantasy superior to the wording phantasy of the gang's four.
The camera lens was a really nice metaphor for the Adapter pattern.
I always had a cable adapter in mind, which admitteldy does still explain the gist of it. But doesn't quite convey the risk of overdoing it at unneeded parts of the program.
Was there a distinction in the GOF book between this and the Bridge pattern? Because I vaguely remember the Bridge doing something else.
So glad to see a great engineer with same thoughts about the distinction between "programmer consumer" and "programmer creator".
Great explanation, do you have another video of explaining all design pattern explained in similar fashion? Please share.
This was extremely helpful. Thank you.
Yes, we have to keep in mind that patterns are meant to make maintainable code. If it gets too complicated, then the purpose is defeated.
Enlighten me, please. How/what it has to do with maintainability?
I really like this revisiting of old school software ideas but re-explained/-considered
Awesome ❤️ @brad and guests 🙏
Could you also make a video on Filter Design Patterns like those needed in eshops?
awesome, can you explain some good design patterns for state machine handling and command/response handling. thanks.
Good video! Happy to see more theory on the channel, maybe some datastructure/algorithm videos?
Nothing to do with theory. Just naming of different wheels.
Off topic :
Is UML still needed other than for communicating our design ?
I feel I need to learn Software Architecture too, including its patterns : layered, microservices, etc. I don't know whether I will have a plenty of time to read books on it, including SOA.
Ahhghgg! A surprise discount Conan O'Brien was surprising... only this one is more interesting, for sure! Great content as always.
Amazing overview! Thank you so much!
When do you consider Singleton as an anti-pattern instead of a pattern?
I'm very wary of singletons that are defined by a business requirement (e.g. we will only ever connect to one payment system, etc.) Singletons for technical reasons (e.g. this is the Singleton for talking to this micro-service) are usually ok.
Doesn't your example confuse Bridge pattern with Polymorphism paradigm?
What design pattern is most used in tutorials for beginners?
Bridge and Adapter patterns are two different things. Bridges are usually written up front and Adapter's are usually written as an afterthought. A good Bridge analogy is like front-end/back-end paradigm. AJAX is the Bridge pattern between the two. Or OS API/GUI the graphics driver is the Bridge.
The bridge pattern is meant to decouple an object's abstraction from its implementation using subtyping, allowing either side of the coupling to be updated or interchanged separately. It doesn't just connect two technologies together. Ajax is not an example of Bridge.
A Bridge example would be: imagine having a data model object that accesses a database, but you want to be able to swap out the database and the data model independently. The Bridge pattern is to define an interface for the database and an abstract class (or interface, depending on language) for the data model object and use those as the basis for your objects.
So you might define an interface Database with methods such as find(), save(), and so on. You then define an abstract class DataModel which takes an object of type Database as a property. Now you can have interchangeable DataModel objects like a Customer, Product, SalesOrder, and so on, and you know that the Database methods find() and save() will always be available regardless of what database you use because those methods were defined on the Database interface.
Adapters, by the way, aren't written as afterthoughts. In fact, they have an important use in this example. I can create a wrapper class (which is all an Adapter really is) that implements Database, encapsulate my database driver, and then map the interface's find() and save() method to whatever the equivalent driver methods are. Now I can have a MySQLAdapter, MongoDBAdapter, OracleAdapter, or any other database implementation of type Database and will be able to use them interchangeably with my DataModel objects without fuss.
A very nice presentation and thank you. I hope you don't mind if I share some of my thoughts. Design pattern implementation are just generified implementations of observable/repeatable behavior? And isn't that where their implementations become a problem, specifically when performance enters the equation? We can make almost anything generic but we can't always make them generic and performant. In the end one has to decide, code specifically to the problem or code generically around the problem.
In summar then I question the common assumption that design patterns are a best practice.
I think you misunderstand what design patterns are. A design pattern is really just a solution to a problem. The patterns in the book come from the authors identifying the best ways they have solved the specific problems addressed in the book. The patterns themselves are ideas (techniques) and not specific implementations, therefore the performance of the code implementing the pattern is subject to the skills and understanding of the coder, not the pattern. As an analogy, a dovetail joint in carpentry/joinery is a proven technique for joining two boards together quite strongly. However, if I'm not a very skilled carpenter my dovetail joints may not work very well. Likewise, an excellent carpenter that could make the tightest dovetails with nothing but a chisel would still likely never use dovetail joints when framing walls.
This is what I was looking for. I don't want to be a framework consumer anymore. I want to build my own frameworks. Even if there is no reason for another framework, I'll build it. Coding projects for end-users for 3 years kinda cumbersome, though this job gives me money. I want to build something that might be a useful for other programmers.
Could we get some ASP.NET MVC or ASP.NET Core Web Application (+ Angular maybe?) tutorials here?
Gang of Four book is an absolute classic. I give a copy to every junior dev I ever hire.
What's next book if I already read this book ? Any suggestion ?
I like your clean and simple descriptions of pros and cons and I especially liked your touching on refactoring code from one pattern to another....I feel that micro-services are an embodyment of observer/Pub-sub and soo may eliminate the need to hard code the logic of the pattern....my own view is evolving to imutable (where possible) event stream workflow sagas of micro-services in containers.
I like the use of UML in visualizing/creating patterns (and anti-patterns).
There is a typo in your description, unless we're talking about dome important software design patterns and it's dome related. Great video!
Thanks
So finally, Conan O'Brien learned to code.
Great stuff and thank you Jack. I felt like you dropped the real truth at 7:50 :)
Hey do add MVC Design Pattern and Factory Design Pattern. Or i missed them in the video?
I'm new into this..
Why don't we just use static classes instead of using singleton pattern? What's the difference?
I really liked this video. Great perspective.