5 Design Patterns Every Engineer Should Know

In this video we will talk about some important software design patterns
Jack Herrington KZbin Channel:
/ @jherr
Timestamps:
0:00 - Intro
2:14 - Singleton Pattern
3:51 - Facade Pattern
5:48 - Bridge/Adapter Pattern
8:02 - Strategy Pattern
9:48 - Observer Pattern

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

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

[@peerreynders1824]

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

[@peerreynders1824]

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.

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

[@surfviewgardens2396]

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

[@adnan4750]

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

[@akocbowievillasenor9592]

Gold

[@user-rt4ly8ex9x]

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

[@Mark98T]

what a sad comment, isn't it?

[@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!

[@tamasbalint1597]

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

[@MrMuscidae]

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

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

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

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

[@TheNerdyDev]

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

[@avinashd2481]

Hey Jack, your overview on design patterns made me rethink those services that I used unconsciously at my job and thank you for the valuable insights.

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

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

[@EnLaMitad]

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

[@prashantmishra5691]

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

[@SpencerYork1534]

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

[@siphiwocode]

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

[@Eghizio]

Monke Flip

[@SuperAwesomeReasons]

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

[@oldbootz]

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

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

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

[@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!

[@jansmycka4338]

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

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

[@ShaunForan]

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

[@charlesbaldo]

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

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

[@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 👍👍

[@ArquimedesOfficial]

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

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

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

[@jamesharris3109]

Thank you so much for making editing, & posting this video.

[@TheAngelOfDeath01]

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

[@Nicxlive]

One of the best tech videos I have ever seen

[@manfredconnor3194]

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

[@Infinitude]

Thanks for sharing the design patterns, Loved the Content.

[@AlmantasKarpavicius]

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

[@AlmantasKarpavicius]

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

[@AlmantasKarpavicius]

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

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

[@nirmalkumar3282]

Thanks Brad, Thanks Jack for sharing the information

[@DevPremier]

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

[@SteveBetner]

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

[@freekeys]

Awesome ❤️ @brad and guests 🙏

[@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)

[@AnimeSongsNightcore]

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

[@ErsinFahredin]

Thanks for the info!

[@mastercdgb]

This was very informative Brad. Thank you very much. I would really love to see some videos on system design and architecture.

[@mandihaase2744]

Amazing overview! Thank you so much!

[@eesakamaldien1917]

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

[@ramchillarege1658]

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

[@bokunochannel84207]

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

[@aaronalquiza9680]

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

[@mikesanders8397]

This was extremely helpful. Thank you.

[@angeloluisrocattojunior3425]

Template Method is a good Design to learn too. It's used in the PHP Frameworks (Laravel, Zend) and in Java, e.g., in Servlet classes.

[@kimdavidj2]

Thank you for the video, well explained!

[@ahmedp8732]

Thanks Brad. Great content! I would really like to see some .Net core projects using VS code. I use Linux Ubuntu, so I can't use Visual Studio. With .Net 5 on it's way, I think there will be a renewed interest in .Net development.

[@anitin3]

Great explanation Thank you

[@Gadrawingz]

The world 🌎 pays much respect these men!!

[@muneebmukhthar4880]

Sincerely i watched this many times to understand!😉

[@manueldiera6781]

This was excellent!! Thank you.

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

[@alexgochenour8740]

I really liked this video. Great perspective.

[@wzpu3283]

Thank you Sir for the excellent explanations.

[@zunnfix8295]

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

[@mar25947]

I was looking for this comment,lol 🤣

[@LuisPerez-mw5kl]

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

[@HSharpknifeedge]

Thank you! Great video.

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

[@slavuter]

thanks brad and your videos are awesome!👌

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

[@bommaritohawaii]

Good work Jack!

[@eigentlichtoll02]

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

[@sabuein]

Thank you, Jack.

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

[@adventurer2395]

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

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

[@hbar45]

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

[@atmospheric_b]

Jack is awesome. Thanks

[@hemantgaikwad3352]

Nice information. Thank you! 👍

[@TheDibs4]

Thanks for discussing the cons also

[@islamicsolution5618]

Very informative topics you discuss.

[@shoaibahmed342007]

Thanks for the knowledgeable video.

[@marlonmagonjo5693]

Much appreciated👊🏽

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

[@vinidevjiu]

i love your videos...i ve done some of yours courses in udemy. Great content!

[@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!

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

[@firebrickfilmstv]

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.

[@shubhamchandra9258]

pretty darn amazing.

[@elpmid]

This is so helpful. Thanks!

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

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

[@turokII]

Great content, thanks!

[@9888622400]

Thanks Man, Amazing Video!!

[@andrijavranic5058]

Dear Brad, this was such a cool move! kudos and restepkah ;)

[@XinoMbr]

Thank you for the content! :)

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

[@TheAceInfinity]

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

[@ryadderdar991]

awesome talk, thanks !

[@P1oN4ik]

Thanks! Nice video! Need more something like that ))