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)" ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-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)" ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-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.
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.
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.
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!
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.
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
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 .
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.
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.
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
"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.
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.
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 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.
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).
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!
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.
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!
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).
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.
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?
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.
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.
The bridge pattern is not the same as the adapter pattern. An adapter is a secondary layer of code that translates code from another codebase into a form that a new codebase can understand. A bridge is a method of decoupling codependent components by feeding them a contract rather than each other as dependencies.
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.
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.
4 года назад
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 года назад
@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 года назад
@@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.
Bridge/Adapter Pattern is similar to the concept of Hexagonal / Clean / Onion Architecture. The point of this pattern is to be independent of external changes while keeping the business logic (i.e. Core Application / Use Case and Core Domain) intact.
Just to clarify, the Bridge and Adapter patterns are two separate patterns. And they are both commonly used in the implementation of the architectures you mention, the Bridge pattern being essential to decoupling layers/concerns.
