5 Design Patterns Every Engineer Should Know

[@jherr]

Thanks again Brad for hosting my video on your channel. It's great that you are giving creators this opportunity.

[@TraversyMedia]

Thanks for letting me, Great stuff!

[@jackiepuppet_5324]

Spreading the word of GoF, thanks Jack! Brad, can we see unit testing (maybe even TDD) in React soon?

[@TheCodeRank]

Superb info

[@bogdankyuchukov2124]

It's a very useful and important video. Thanks to both of you 🙏🏻

[@MrSidMan]

Great overall guide.

[@KeshaShah1106]

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)

[@Aced_Dreamer]

cool

[@duanalfred8867]

thanks for your summary

[@marshalnzenza6732]

thanks

[@aliasalias510]

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 :)

[@gamersforever1585]

thank you for this comment

[@PeerReynders]

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)" kzbin.info/www/bejne/qaO0pWSEdq2MeZI 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).

[@w1d3r75]

Also, patterns are not mandatory. Don't try to force a pattern implementation

[@PeerReynders]

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)" kzbin.info/www/bejne/qn66YWuAoKuleKM 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.

[@lexsoft3969]

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.

[@surfviewgardens2396]

Who knew that Conan O'Brien is a coder? Fascinating.

[@adnan4750]

😂😂not me.....and yes they look the same

[@akocbowievillasenor9592]

Gold

[@박수경-m4b]

Hmmteresting

[@cristian5370]

If Conan and Chris Hansen fused

[@manikantaraju9137]

😂 👌.... Lil chubby tho.

[@hcx1853]

2:14 Singleton Pattern 3:50 Facade Pattern 5:47 Bridge/Adapter Pattern 8:02 Strategy Pattern 9:48 Observer Pattern (PubSub)

[@keithprice7119]

The timestamps are already in the description.

[@MrNsaysHi]

And already divided into chapters

[@kwakuboateng8067]

@@MrNsaysHi 00 Z yi

[@TigerByteID]

what a sad comment, isn't it?

[@ericvosselmans5657]

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.

[@aarishmahmood8865]

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.

[@Rustcode]

2:10 Singleton Pattern 3:30 Facade Pattern 5:40 Bridge/Adapter Pattern 8:00 Strategy Pattern 9:50 Observer Pattern (PubSub) Informative video 👍👍

[@CodeJourney]

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!

[@msc8382]

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.

[@voltydequa845]

Ah, I wonder what was the programming life before the era of patterning the common sense.

[@jansmycka4338]

Holy cow, the first minute hits the nail on the head SO MUCH. I am "Senior" but still lame Framework consumer.

[@tamasbalint1597]

I love the way you talk about design patterns and giving fantastic examples. Thank you so much for sharing your knowledge.

[@StarContract]

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

[@bokunochannel84207]

software architecture is harder than technical coding, glad this tutorial exists.

[@lighttravel3407]

Having quit development 25 years ago and looking to jump back in, it is great to see the same book still being used.

[@gilian2587]

Principles are valuable. They always have been, and they always will be.

[@EddyVinck]

I love the Facade Pattern. One of my other favorites not covered in the video is the factory pattern in JavaScript. Watching this later!

[@thatoneuser8600]

Which factory; there are so many different types of factory patterns

[@matthewzecchini9951]

Great topic! Just started studying design pattern and SOLID. Makes you understand HOW to write software vs writing code.

[@gamersforever1585]

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]

And what would be the differsnce?

[@matthewzecchini9951]

@@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.

[@uoweme5grand]

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!

[@adventurer2395]

Adapter pattern is so essential for extending software. Should def be here.

[@fouksmam]

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.

[@dhrubanka6197]

Much needed.. The thing most beginners misses

[@TraversyMedia]

I agree. I did not even look into design patterns until maybe 2 years after I started coding

[@dhrubanka6197]

Thanks brad for the reply. Hope to see a cool series on Design patterns soon

[@mykalimba]

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.

[@Foozie3moons]

To be fair, programming design patterns require a certain level of proficiency to fully comprehend.

[@sokoyaadedolapo5321]

Yes you're right

[@ShaunForan]

I'm a simple man...I see a video by Jack, I give a like. Awesome content!

[@siphiwocode]

"There can be only one" classic. Thanks for the video, much appreciated

[@Eghizio]

Monke Flip

[@MrMuscidae]

Best description of the Facade pattern that I ever heard, the compiler analogy was brilliant!

[@palwan7190]

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

[@albirtarsha5370]

Now that you know the names you are a 10x programmer!

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.

[@msc8382]

@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.

[@xellos5262]

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.

[@maxb5919]

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.

[@Julio860JVL]

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.

[@davidnichol4735]

Right? It seems so obvious now...

[@karaway2117]

syndrome Was The Imposter

[@pranavambhore9215]

You're a sus? Me too.

[@ramchillarege1658]

Stumbled across your video. Nice presentation. Thanks. Wonderful to hear about this.. Vlissides was a great guy. My friend from days gone by.

[@ibrahimkconteh]

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 .

[@idespisegravity]

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!

[@DevPremier]

Design Patterns Series could be The Most awaited series and Most useful series for everyone besides of their stack.

[@EnLaMitad]

I love what's going on with this channel lately. Subscribed to Jack's channel. Thanks.

[@eesakamaldien1917]

You are the best teacher... You are my guru now

[@manfredconnor3194]

I really enjoy your videos. I wish I was as good at following through as I am at watching them.

[@nomoreabdi745]

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

[@micknamens8659]

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).

[@zunnfix8295]

I didn't know Conan O' Brian was also an engineer. Brilliant!

[@mar25947]

I was looking for this comment,lol 🤣

[@jasonpmcneill]

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.

[@pedrokalil4410]

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.

[@TheNerdyDev]

Jack is a great guy. Thanks for sharing your knowledge and experience on the channel. Really enjoyed the video !

[@cyizarwanda5488]

It's nice to finally put a face to the voice of the man who has made me into the man I am today...

[@Nicxlive]

One of the best tech videos I have ever seen

[@ErikBongers]

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.

[@cassolmedia]

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.

[@ilovelctr]

This man sounds so elegant, which is a particularly rare quality for stereotypical coders.

[@ramdaneoualitsen1323]

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.

[@slavuter]

thanks brad and your videos are awesome!👌

Great overview of the most important patterns (in my opinion)!

[@Gadrawingz]

The world 🌎 pays much respect these men!!

[@rickyrayrosenberg420]

Gang of Four book is an absolute classic. I give a copy to every junior dev I ever hire.

[@SuperAwesomeReasons]

Love the framework consumer vs framework creator bit at the beginning!

[@SpencerYork1534]

This video is of the highest quality. Love the content. Love the production.

[@TheAceInfinity]

Factory pattern and Builder pattern are two other ones that I think are also very useful.

[@its_magnetic]

Thank you. Love and respect 🙏 from Sikkim, India 🇮🇳.

[@siddharthkr.6193]

Shut up I am from India too okay but this shows that you are one of the freaks who write "love from India

[@nickfausti6194]

This is incredible, thank you! Amazing how you can turn something as (seemingly) dry as design patterns into something entertaining and informative. Well done.

[@AP-bo1if]

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.

[@TechWithPat]

"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.

[@KiddyLovely93]

thank you so much

[@dmitry9728]

Read the title, looked at description, calmed down because all listed patterns already known :)

[@lexsoft3969]

Memento is fun name missing here. I will see if I want to try implementing it.

[@oldbootz]

High quality content, loving it! Got my like when you whipped out that old book!

[@stefan4800]

Very surprised that the Factory pattern in not on the list. The Command pattern is very cool too.

[@jherr]

It was a tough call. Had to pick five. But Factory would have been in there if I'd done more.

[@TheAngelOfDeath01]

I can attest to each and every one of these. Good video for everyone from beginners to advanced old timers.

[@killionaire175]

That book must be on every developer's bookshelf, period.

[@prashantmishra5691]

Loved it. Must watch for all devs. Thanks for this Jack. Thanks again, brad.

[@mr.minister5018]

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!

[@hbar45]

10:20 I remember experimenting with the Observer Pattern and exactly this happened to me. I felt that in my soul.

[@eigentlichtoll02]

I really like this revisiting of old school software ideas but re-explained/-considered

[@LuisPerez-mw5kl]

Excellent video, thanks a bunch, greetings from Mexico - Oaxaca

[@EduardKaresli]

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.

[@voltydequa845]

A good programmer has a creative phantasy superior to the wording phantasy of the gang's four.

[@ShaolimMatadorPorco69]

So glad to see a great engineer with same thoughts about the distinction between "programmer consumer" and "programmer creator".

[@WarrenBey]

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.

[@chrislangtiw6395]

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.

[@tomas4298]

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.

[@aaronalquiza9680]

my favourite pattern is probably Memento with performance optimizations. it allows me to exercise my skills on many different data structure algorithms.

[@gigabek]

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.

[@samthomas200]

I would strongly recommend the MV* pattern as well for any non-trivial web development (can be extended to toher use cases as well)

[@charles-y2z6c]

Thank you, i finally understand Singleton and it was so straightforward.

[@Hyuts]

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.

[@harshalagrawal03]

So finally, Conan O'Brien learned to code.

[@henrytan5707]

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.

[@tofa8608]

Have a great day too, be happy and safe!

[@AgrimGrover]

Great explanation, do you have another video of explaining all design pattern explained in similar fashion? Please share.

[@bonnoManus]

I wish you had some UML diagram to show the patterns. But overall the video was a nice refresher.

[@randomuser66438]

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.

[@voltydequa845]

Enlighten me, please. How/what it has to do with maintainability?

[@somebinchicken]

Good video! Happy to see more theory on the channel, maybe some datastructure/algorithm videos?

[@voltydequa845]

Nothing to do with theory. Just naming of different wheels.

[@alvenalinan]

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.

[@chrislangtiw6395]

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.

[@RoyRope]

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?

[@mikesanders8397]

This was extremely helpful. Thank you.

[@WanderingAdventurer-d7i]

[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.

[@cemery50]

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).

[@shehzadmalikmomin2988]

Please make similar kind of video for Data Structure & Algorithms. ‘N’ DSA every engineer should know.

[@gl4606]

Hey guys just wanted everyone to know I'm enjoying this video on the toilet 😁

[@TraversyMedia]

lol I guess it's better than playing candy crush. At least it's a productive shit

[@gerardjayetileke4373]

I'm not sure how to thank you xD

[@Julio860JVL]

Please hurry up cuz I need to use the toilet too.

[@alwynjohn597]

Same here. Right now I am in toilet watching this video and reading this comment.

[@miketharipr]

That's a crappy design pattern.

[@NyscanRohid]

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.

[@algchoo]

There is a typo in your description, unless we're talking about dome important software design patterns and it's dome related. Great video!

[@TraversyMedia]

Thanks

[@nirmalkumar3282]

Thanks Brad, Thanks Jack for sharing the information

[@antonfernando8409]

awesome, can you explain some good design patterns for state machine handling and command/response handling. thanks.

[@AnimeSongsNightcore]

Please more videos about best practices, design patterns and advanced topics. I love your explanation.

[@luiscarloscruzcastillo3192]

I learnt the strategy pattern from Head First Design Patterns, I think that change the behavior of a object in runtime it's kind of cool

[@individual14x]

@Jack Herrington Isn't the "Strategy" pattern better suited to be a called a microservices architectural approach ?

[@balsubu1]

very nice.. in the web world the API gateway is a great Facade pattern

[@Schodemeiss]

Ahhghgg! A surprise discount Conan O'Brien was surprising... only this one is more interesting, for sure! Great content as always.

[@wulymammoth]

I wish there was an explanation as to why these patterns in particular. It really depends on the software being written on what these patterns should be. There's also a HUGE HUGE HUGE caveat -- misapplied abstractions such as these design patterns make people irk and the software written to be more rigid and people end up writing things to circumvent it so it just becomes a fire atop an already dumpster fire. Secondly, the hand-wavy explanation of "leaky abstraction" leaves a lot to be desired and I'm sure it has some scratching their heads. Generally this means when implementation details leak into a higher level or abstraction layer. If you're working with a an ORM to perform CRUD operations against a DB, the driver whether it is for MySQL or Postgres or something else likely shouldn't appear in the code we're writing or the ORM code at all. If someone can reach around the exposed/public interface, it can also be considered a leak. It's really about leaking lower-level details into higher-level ones. I'm of the opinion that people shouldn't even apply these patterns until they've understood the SOLID acronym and the principles they represent before trying their hand at implementing GoF ones.

[@johnkyp1318]

Could you also make a video on Filter Design Patterns like those needed in eshops?

[@osamaa.h.altameemi5592]

Can we safely say the strategy pattern is the basis for micro-services? Fantastic video, what about doing a series for the entire book. Once again, thank you.

[@k4nful]

1:29 : My compagny using a homemade framework (a jsp and html code generator) made 12 year ago by a students group at univresity. As they were junior, they built it without using any DESIGN PATTERNS so we can't do this list of great things 1:29. Today the app developed with the framework is used by > 200 customers, and THIS A REAL NIGHTMARE TO MAINTAIN THIS BLOODY APP. Design pattern must be mandatory in any developers schools.