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)" ua-cam.com/video/srQt1NAHYC0/v-deo.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)" ua-cam.com/video/tMW08JkFrBA/v-deo.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.
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!
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
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!
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.
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.
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.
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 .
Stumbled across your video. Nice presentation. Thanks. Wonderful to hear about this.. Vlissides was a great guy. My friend from days gone by.
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.
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
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).
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.
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.
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.
[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.
"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 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.
This is incredible, thank you! Amazing how you can turn something as (seemingly) dry as design patterns into something entertaining and informative. Well done.
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!
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.
People always want to treat software development as a production process, like what factories do, but in fact it's a prototyping process, like building a prototype car or airplane. It needs a lot of ideas to make it wholesome, so you know how you should approach it.
Great video. Only one comment, Pub/Sub is not the same as Observer. In the Observer pattern the publisher knows the subscribers and reports update directly to them. In the Pub/Sub pattern the publisher is more like a publisher in the real world, they do not know who is interested in the data published, they just publish and the consumers look into a broker for messages they care about.
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.
my favourite pattern is probably Memento with performance optimizations. it allows me to exercise my skills on many different data structure algorithms.
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).
"Five engineers patterns should know": gardener, landscape gardener, landscape designer, landscape architect, landscape engineer! Now, that's about as simples, as simple can be... Mega simples (:-)
Thanks a lot! Great video, also for me my favorite pattern is strategy and with observable rxjs with angular I can learn the best practise to build solid and reusable component that access to data async and modelling data angular only when subscribe is finished. Awesome . See u
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.
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)"
ua-cam.com/video/srQt1NAHYC0/v-deo.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)"
ua-cam.com/video/tMW08JkFrBA/v-deo.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.
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.
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.
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.
2:10 Singleton Pattern
3:30 Facade Pattern
5:40 Bridge/Adapter Pattern
8:00 Strategy Pattern
9:50 Observer Pattern (PubSub)
Informative video 👍👍
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.
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 can be only one" classic. Thanks for the video, much appreciated
Monke Flip
I'm a simple man...I see a video by Jack, I give a like. Awesome content!
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
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!
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.
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 description of the Facade pattern that I ever heard, the compiler analogy was brilliant!
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
software architecture is harder than technical coding, glad this tutorial exists.
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
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.
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 .
Adapter pattern is so essential for extending software. Should def be here.
Stumbled across your video. Nice presentation. Thanks. Wonderful to hear about this.. Vlissides was a great guy. My friend from days gone by.
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.
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
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 love what's going on with this channel lately. Subscribed to Jack's channel. Thanks.
Jack is a great guy. Thanks for sharing your knowledge and experience on the channel. Really enjoyed the video !
This man sounds so elegant, which is a particularly rare quality for stereotypical coders.
Design Patterns Series could be The Most awaited series and Most useful series for everyone besides of their stack.
Great overview of the most important patterns (in my opinion)!
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
It's nice to finally put a face to the voice of the man who has made me into the man I am today...
One of the best tech videos I have ever seen
Gang of Four book is an absolute classic. I give a copy to every junior dev I ever hire.
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).
The world 🌎 pays much respect these men!!
Love the framework consumer vs framework creator bit at the beginning!
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.
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.
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.
I can attest to each and every one of these. Good video for everyone from beginners to advanced old timers.
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.
Read the title, looked at description, calmed down because all listed patterns already known :)
Memento is fun name missing here. I will see if I want to try implementing it.
[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.
So glad to see a great engineer with same thoughts about the distinction between "programmer consumer" and "programmer creator".
"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 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.
I didn't know Conan O' Brian was also an engineer. Brilliant!
I was looking for this comment,lol 🤣
This video is of the highest quality. Love the content. Love the production.
High quality content, loving it! Got my like when you whipped out that old book!
Excellent video, thanks a bunch, greetings from Mexico - Oaxaca
This is incredible, thank you! Amazing how you can turn something as (seemingly) dry as design patterns into something entertaining and informative. Well done.
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!
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
thanks brad and your videos are awesome!👌
This was extremely helpful. Thank you.
I really like this revisiting of old school software ideas but re-explained/-considered
Factory pattern and Builder pattern are two other ones that I think are also very useful.
That book must be on every developer's bookshelf, period.
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.
Loved it. Must watch for all devs. Thanks for this Jack. Thanks again, brad.
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.
People always want to treat software development as a production process, like what factories do, but in fact it's a prototyping process, like building a prototype car or airplane. It needs a lot of ideas to make it wholesome, so you know how you should approach it.
I would strongly recommend the MV* pattern as well for any non-trivial web development (can be extended to toher use cases as well)
Ahhghgg! A surprise discount Conan O'Brien was surprising... only this one is more interesting, for sure! Great content as always.
Thank you, i finally understand Singleton and it was so straightforward.
Great video. Only one comment, Pub/Sub is not the same as Observer. In the Observer pattern the publisher knows the subscribers and reports update directly to them. In the Pub/Sub pattern the publisher is more like a publisher in the real world, they do not know who is interested in the data published, they just publish and the consumers look into a broker for messages they care about.
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.
Very informative topics you discuss.
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.
my favourite pattern is probably Memento with performance optimizations. it allows me to exercise my skills on many different data structure algorithms.
10:20 I remember experimenting with the Observer Pattern and exactly this happened to me. I felt that in my soul.
Nice information. Thank you! 👍
Have a great day too, be happy and safe!
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 Brad,
Thanks Jack for sharing the information
Thank you Sir for the excellent explanations.
Sincerely i watched this many times to understand!😉
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
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?
Hey guys just wanted everyone to know I'm enjoying this video on the toilet 😁
lol I guess it's better than playing candy crush. At least it's a productive shit
I'm not sure how to thank you xD
Please hurry up cuz I need to use the toilet too.
Same here. Right now I am in toilet watching this video and reading this comment.
That's a crappy design pattern.
Thank you Coder O’Brien!
"Five engineers patterns should know": gardener, landscape gardener, landscape designer, landscape architect, landscape engineer! Now, that's about as simples, as simple can be... Mega simples (:-)
Please more videos about best practices, design patterns and advanced topics. I love your explanation.
Great stuff and thank you Jack. I felt like you dropped the real truth at 7:50 :)
Thanks a lot! Great video, also for me my favorite pattern is strategy and with observable rxjs with angular I can learn the best practise to build solid and reusable component that access to data async and modelling data angular only when subscribe is finished. Awesome . See u
Amazing overview! Thank you so much!
Thanks Man, Amazing Video!!
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.
Thanks for the knowledgeable video.
Good advice
very useful. thanks for sharing.
Awesome ❤️ @brad and guests 🙏
very nice.. in the web world the API gateway is a great Facade pattern
Thank you! Great video.