5 Design Patterns That Are ACTUALLY Used By Developers

Design patterns allow us to use tested ways for solving problems but there are 23 of them in total and it can be difficult to know which ones to pay attention to. In this video I cover what exactly design patterns are and the top 5 that I have used the most in my career.
☕️ I don’t accept paid sponsorships and I have turned off mid-video ads. You’re welcome! If you would like to support my channel see: ko-fi.com/alexhyett
📨 Join my free weekly newsletter for advice, technology and more: newsletter.alexhyett.com
🗺️ Backend Developer Roadmap: www.alexhyett.com/backend-dev...
📝 Transcript: www.alexhyett.com/design-patt...
🎓 RECOMMENDED COURSES (Use code FRIENDS10 for 10% off)
The Complete Web Developer Course - academy.zerotomastery.io/a/af...
The Complete Junior to Senior Web Developer Roadmap - academy.zerotomastery.io/a/af...
C#/.NET Bootcamp: The Fundamentals: academy.zerotomastery.io/a/af...
Complete SQL + Databases Bootcamp - academy.zerotomastery.io/a/af...
📚 RECOMMENDED BOOKS
Clean Code - geni.us/5AEwj2
Design Patterns - geni.us/5ncUt
Developer Hegemony - geni.us/lAXy
Pragmatic Programmer - geni.us/GfNj9
Data Structures and Algorithms Made Easy - geni.us/sqg6kJ
Refactoring - geni.us/ufAP0mE
Pragmatic Thinking and Learning - geni.us/x81A
⏳ TIMESTAMPS
00:00 - Introduction
00:37 - What is a Design Pattern?
02:01 - What are the Design Patterns?
03:27 - Strategy Pattern
04:38 - Decorator Pattern
05:27 - Observer Pattern
06:18 - Singleton Pattern
07:47 - Facade Pattern
🧑🏻‍💻 You can check out more of my favourite tools on my website: www.alexhyett.com/tech/
🔗 MY KEY LINKS
🌍 Blog - www.alexhyett.com/
🐘 Mastodon - social.alexhyett.com/@alex
🧑‍💻 WHO AM I
I’m Alex, a Software Developer and KZbin working in the UK. I make videos about software development to help developers with the skills they need to be senior developers. As well as this KZbin Channel, I also write articles on my website (alexhyett.com) as well as write a regular newsletter that contains some thoughts to help aspiring developers.
‼️ DISCLAIMERS
Some of the links in this description are affiliate links, for which I get a small commission, at no extra cost to you 🙂. I appreciate you supporting my channel so I can continue providing you with free software development content!
#coding #programming #developer

[@CuriousCyclist]

Thank you for taking the time to make this video. Much appreciated.

[@cirusa12]

Just stumbled upon this channel and as a new dev, I'm loving the bite-sized videos that each explain a useful concept / topic!

[@MasterSergius]

But you need to know 100 design patterns at interview for a junior position

[@LearnAnyCoding-vg6up]

Would you share me what are they? do you have any links or resources? I am junior dev so i need to prepare for interview.

[@Foxtrot6624]

@@LearnAnyCoding-vg6up go read Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of Four. This book is essentially where the idea of design patterns came from and is seen as the most important book in object oriented programming

[@ryanqvincent144]

I agree with you completely about these commonly used patterns. They really are so useful in 'real programming life'. I also agree that it is well worth appreciating the other patterns as they really are useful in specific circumstances. Thanks for this. Appreciated.

[@gx2244]

Thank you for making this. I'm very hands on and have definitely used these before without even realising what they were called.

[@levon9]

Fantastic video -- thank you! I plan to check out your other videos, perhaps find more design pattern goodness. Subscribing either way.

[@TheSeaOfAsher]

I agree the bite-sized concept are well explained. I subscribed I hope to see more.

[@IvanToshkov]

One very important aspect of the design patterns is that they depend on the language and its capabilities. This means that in higher-level languages you can implement some of the patterns as algorithms. In this sense, design patterns can be thought of as a relatively good way to go around limitations of your language. As an example, let's take the singleton pattern. It was introduced in book, because there's no way to make it as a library code in C++[1]. But for example in Java[2] you can use a dependency injection library and you can just annotate your class with @Singleton. The library will take care of the rest. Another example where the pattern all but disappears is the strategy pattern. Languages that support higher-order functions can just use them instead of the pattern. ---- [1] Or at least you couldn't at the time. I haven't been following recent C++ development. [2] I don't know enough C# to show similar example, sorry.

[@yurcchello]

in singleton pattern example using Lazy is wrong, value field can be initialized in race conditions. for this scenario can be used static function LazyInitializer.EnsureInitialized(T, Func)

[@user-tk2jy8xr8b]

Class init in .Net is thread-safe, so no issue there Even Lazy is not required unless you really need lazy init

[@Daniel3Levi]

Thank you ! amazing video

[@krccmsitp2884]

Builder and Template Method are two other patterns I use occasionally.

[@jonasoliveira8909]

Amazing way explaining these patterns.

[@0xKobby_dev]

That cake and birthday party analogy was very good. Thanks for the video.

[@alexhyettdev]

Thank you, I am glad! I wasn’t sure if it was a bit too abstract.

[@adrianbilescu]

@@alexhyettdev just perfect. I love it too

[@eser-sahin]

Great explanations thank you for your effort. Which color theme do you ise in Vs Code?

[@alexhyettdev]

Thank you! It is the Atom One Dark theme: marketplace.visualstudio.com/items?itemName=akamud.vscode-theme-onedark

[@professorfontanez]

I used the facade design pattern once to simplify this widget I created. When I generated the Javadoc, I blew my lead's mind as to how simple it was to use. I did not need to create any documentation because there were only a handful of exposed methods and the names of these methods were very explicit.

[@MrBlaDiBla68]

You managed to make the KZbin "please subscribe" message an integral part of your vid. Well done ;-) . And the rest of the vid too, of course, I'm a CS grad and have read this valueable book thoroughly...

[@yognirog]

much helpful, and a nice explanatory video to start with zero knowledge of design patterns.

[@alexhyettdev]

Glad it was helpful!

[@khalidelgazzar]

Great explanation. Thank you

[@alexhyettdev]

Glad you liked it

[@tekforge]

I really like your metaphor at the beginning!

[@alexhyettdev]

Thank you! I am never 100% sure whether my metaphors are helpful

[@omgmaw]

How about the Command Design Pattern. I use the pattern often

[@HasinthaWeragala]

thanks for this most noble sire

[@achrefnabil2463]

Man you deserve 1m subscribers ❤❤ can you make a node js DDD hexagonal archeticture CQRS Event sourcing course

[@alexhyettdev]

Thank you! Yes I might be able to do a course on that in the future.

[@airixxxx]

Great video. Never heard about the Facade pattern, when you started explaining it I thought it was the Adapter pattern, What's the difference between them?

[@PixelThorn]

An adapter can be a function, or class, which acts as a translator between one functions/class output and another's input Facade is more like a nice function, or class, that's easy to use and acts as the main interface/function which hides a lot of ugliness underneath to get things done A facade of a house hides all the details on the inside, but you get a basic idea on what the house is used for by checking it's exterior - it's facade - see a police building for example

[@airixxxx]

@@PixelThorn Thanks!

[@fifty-plus]

A facade doesn't have to be a nice abstraction on top of a mess. It could be you just want to abstract multiple types behind an interface so all types (usually of a third party) look the same, i.e. they have the same facade, to the consumer of them - otherwise the consumer would need to know each implementation. An adapater is about translating something into something else and acts like a middelware between the two things.

[@RickGladwin]

@@fifty-plus 💯 That’s when I’ve used a facade pattern in the past - when our application needed to send messages and make calls to outside services, and we knew we’d be swapping out those services over the next few months. All our internal classes called simple, standardized methods on the facade, and we just updated the internals of the facade to handle the various API implementations of the external services. Kind of an adapter as well? But the reason why we did it was to keep things clean and stable over time.

[@thegooddoctor6719]

Wow - Thanks for the great content.

[@alexhyettdev]

You're welcome! Thanks for commenting

[@felipefs106]

I can see these being used for the backend, But for something like React I find it a bit difficult to adapt these

[@hyperborean72]

So Strategy pattern is actually the same as programming in interfaces (or polymorphism)?

[@sumant2000]

background is awesome. purple color. nice. how much it all costed.

[@cntaasdd]

7:26 how about locking before the null check? Why would you duplicate the code and add more nesting, when you can simply lock before the if...

[@BrandyBalloon]

If you do it that way, the lock will be performed every time GetInstance() is called. It will only be null once, so the way it's done in the video will require two locks at the most, probably just one.

[@zo1dberg]

That's what I thought too. Don't need to check twice if one thread is being locked out whilst the other is creating the object.

[@zo1dberg]

You could say that the concept of a recipe is a design pattern. It's structured so that it has a list of ingredients, and the method for making the food.

[@NoahNobody]

It makes sense to learn the top 5 design patterns first, thanks.

[@alexhyettdev]

Yes there are so many of them, got to start somewhere. I am sure there are a few I have never used as well.

[@fifty-plus]

While it's good to know about singletons, you genereally don't want to explicitly codify them. It's almost always best to let your DI container give you one.

[@technicalboy1816]

what lights are you using?

[@karim_ghibli]

To people from JS/Python like me who were confused about the use-cases of the Strategy Pattern, the simple example shown here don't really fit these languages. In Python/JS it'd be more natural to simply map these functions to the variables or even map them to the methods/strategies names as keys in a dictionary (since JS/Python have functions as first class citizens). However, if these functions need to preserve state, or if they have a lot of shared data between them, then can be used coded as the Strategy Design Pattern.

[@alexhyettdev]

Thanks for providing some context for Python/JS users. Yes all the examples shown are in C# and would probably be familiar for Java users but don't really work for non OOP languages.

[@Arbiteroflife]

I’ve found that some OO patterns don’t really make sense in Python because of functions being first-class citizens allowing you to pass functions around like a variable, where as other languages are weaker and need these patterns because you can’t simply pass a function. Same thing with Abstract Factory in Python.

[@bundiderp5109]

"Not actually my wife" got me good 🤣

[@alexhyettdev]

🤣

[@Guardian1224]

Great video. As a Java developer I not only use the patterns you mentiond but also Visitor, Factory, Builder and Composite. I think they are very common too.

[@9_vko]

So useful!

[@alexhyettdev]

Glad it was helpful!

[@DiogoLScarmagnani]

Desde o vanilla JS eu já evito usar Node, sempre tento forçar Element. Por exemplo, ao invés de pegar o último filho de um elemento com element.lastChild (que inclui todos os Nodes), uso element.lastElementChild (que inclui somente HTMLElements), pois Node pode ser até mesmo os espaços em branco soltos no HTML (por mais que não apareça na tela).

[@thygrrr]

How does Decorator differ from Facade tho...

[@Enhakiel]

Hey... I'm a little confused about the decorator patern, what are the benefits over inheriting the class and overriding a virtual method?

[@fariidev]

The good thing about a decorator is that it can extend any class. So you write a functionality once and plug it in any class that you want, without duplicating code. You can also use it while extending a class you can't access I think, so you can extend a class while not being able to change anything inside it (the open-closed principle he refers to)

[@hyperborean72]

I'm sorry I still did not get it - the prerequisite for the decorator pattern is that one is obliged to use another implementation of the same interface - you just may expand it by putting your extra staff here and there?

[@sowiemarkus]

Yes, that's exactly how you use the pattern. An example would be a logger. The logger has a certain basic functionality that is the same throughout the entire project. In this example, however, you want to save/output the time and the component in which the message was logged for step A. In step B, the time should not be displayed in the log messages. Instead, the type of the log message (warning, error, info ...) should be displayed there. This behaviour can of course be implemented in many different ways. For example, you could add a timestamp attribute to a log message and specify a flag as to whether the date object should also be displayed. This approach works, of course. And in smaller projects, there is definitely no reason not to use such an approach. However, the more such requirements are added, the more complex the code of the class becomes. This means it is more difficult to extend / maintain / understand the code. With the decorator pattern, the logic required for the individual use cases can only be found in the special decorator. This keeps the basic functionality of the logger tidier and therefore easier to maintain. However, if more similar use cases are added, the Decorator pattern is of course an obstacle. Assuming you simply want to be able to switch the individual extras (time, type, location) on and off and you need each of the 2^3 cases in your project, this would mean that you would have to write 8 Decorators with similar functionality.

[@TurboBorsuk]

bringing alcohol to the party is a design pattern

[@Dipesh_Sol]

God Damn It! Now I want all those cakes. Brings back memories of eating all of those in different parts of the world with friends and family Two mnemonics to remember: "Create Structures and Behave: Single Decorated Faces Observe Strategies" Create Structures and Behave: - Create reminds you of Creational patterns. - Structures points to Structural patterns. - Behave refers to Behavioral patterns. Single Decorated Faces Observe Strategies: - Single stands for Singleton (Creational). - Decorated for Decorator (Structural). - Faces for Facade (Structural). - Observe for Observer (Behavioral). - Strategies for Strategy (Behavioral). I like something more fun, so here we go "Crazy Squirrels Build Dens, Often Strategically" - Crazy hints at Creational patterns. - Squirrels Build Dens points to the Structural patterns. - Often Strategically suggests Behavioral patterns. Within each category: - Single (from Squirrels) for Singleton (Creational). - Build (Beginning of Build) for Decorator and Dens (D of Dens) for Facade (both Structural). - Often for Observer and Strategically for Strategy (both Behavioral).

[@Lion_McLionhead]

Lambda functions & closures became the big thing in the last 10 years & probably still are.

[@user-tk2jy8xr8b]

OOP: we identified a set of things called patterns so that you could... FP: JUST USE A FUNCTION FOR THAT (half-joking) Now seriously, to me the top used C# patterns are: - iterator (`foreach`) - factory method (a factory interface injected via DI to make you a factory interface to make you a...) - builder (hostBuilder.ConfigureLogging(...).ConfigureServices(...)....) - strategy (which most of the 2nd-order functions implement) - command (every closure is a command with Invoke method) - interpreter (DSLs are nice) I'm not mentioning singleton here because usually such scope is addressed by a DI-container

[@Zeero3846]

I have reservations against the singleton pattern. Functional style programming combined with immutability kind of makes it unnecessary. If your code doesn't actually care about the object's reference, only it's value, and that value can never change, the optimizations that result is effectively your singleton, and you didn't even have to write it.

[@rosendo3219]

dude is that a 'back to the future' time panel? insta like and subscribe :)

[@alexhyettdev]

It is! I wish it was more than just a light. I might have to make a working one at some point.

[@alexhyettdev]

It here if you wanted on yourself: numskull.com/products/official-back-to-the-future-3d-desk-lamp-wall-light

[@ivandrofly]

Nice

[@ivandrofly]

I'm surprised I know the def of all also how to implement them 😅

[@elramtv]

Man you should put on a cake warning. Now I want some cake.

[@alexhyettdev]

The cake is a lie

[@mnemonicpie]

Finally someone without stupid PewDiePie-style jokes and with good material

[@DonchoGunchev]

Singleton is the worst design pattern I have used. You do want to be able to create multiple DB connections, unit tests and all…

[@flexo9069]

"Not actually my wife" 😂

[@JordanEdmundsEECS]

It’s interfaces all the way down 😂

[@apt2001]

With modern dependency injection a Singleton pattern is very outdated. I personally haven't used it for over 5 years. Moreover, controlling an object lifetime by the object itself seems to conflict with a single responsible principle and would definitely mark a Singleton code down in a code review.

[@TheIcecoldorange]

I have only ever heard about singleton patterns discussed in theory. I have never seen that pattern actually be implemented in the wild. Closest thing is managing dependencies and calling addsingleton, addscoped, or addtransient. I think programmers need to get real about just saying things to look smart.

[@loam]

According to whom I need to know, NASA?

[@IMNODOCTOR]

You use what - Singleton?! Ugh. Nevermind. Ask Allen Holub instead. 😂😂😂

[@toms7114]

You shouldn't use the observer pattern. You should use the event pattern with an event handler class instead. The observer pattern polls and breaks encapsulation. Event patterns act as an interrupt, thus using less process time and only needs to know that the event handler exists and that there is an object that creates an event that you subscribe to through the event handler. edit: The pattern you've described in the video is the event pattern, and not the observer pattern. Please use the appropriate name.

[@jtrc19953]

This video shows a textbook example of the observer pattern. The observer pattern is when a subject maintains a list of its observers and automatically notifies the observers when the subject changes (no polling involved). Using the names Publisher/Subscriber may cause confusion for people familiar with the pub-sub pattern though. As far as I can tell, there's no common pattern called the "event pattern". What are you trying to refer to?

[@TeenyPort]

From my understanding the entire point of the observer pattern (right from the Gang of Four) is to avoid polling. I’m wondering if you may have learned the wrong name for the observer pattern?

[@toms7114]

@@TeenyPort The implementation of the observer pattern I saw was the original small talk implementation from somewhere between the late 70's to the early 90's pre Design Patterns being written, there was a newer version that didn't poll, and then an event pattern that was also available. It made for some rough to follow coding standards. Why I recommend the event pattern is because the observer pattern does break encapsulation by knowing the object being observed has a state you are interested in. The event pattern only requires you to know the object exists, has an event, and there is an event handler object. The object of interest registers with the event handler that it exists and that it has the events it has. The object interested in the events registers its interest in those events from the object. Every object has an event queue. When the object of the events of interest triggers the event it publishes it to the event handler that then distributes it to the subscribed objects. This allows for better debugging process, lowers the risk of operations performing out of order, and removes a variable on all objects of the interested in queue while also allowing multiple actions to be observed improving overall performance. The observer pattern was almost not included in design patterns because of its issues with breaking encapsulation and runtime debugging. I'd say within 5 years of design patterns being published someone invented the event pattern because of all of its superior performance capabilities. The reason it isn't the standard is that every years there are twice as many new programmers entering the job market than the year before so there isn't enough time to develop new programmers and pass on institutional knowledge. Since Design Patterns is the gold standard of how to make a program, even if it is now 30 years old.

[@RyanJensenEE]

skip to 2:45 to skip the preamble and get to the point.

[@alexhyettdev]

That’s why I include time stamps in all my videos. Not everyone knows what design patterns are or wants to listen to my analogies 🤣

[@ralfoeldi]

It is always astounding how people who (probably) believe they are professional developers get all excited about trivial videos like these. Nothing wrong with the video, but ... really?

[@nomsoikem5292]

Really what?

[@HandledToaster2]

Ah yes I too am very smart and professional because I know all my patterns.. clearly I was born this way and never had to learn anything like those puny unprofessionals...?

[@rsauchuck]

I went to your channel. Great content. I can see why you feel compelled to make snide comments about others.

[@calfee62]

Really, you are welcome to go bask in the magnificent glory your ennui.

[@stevenbliss989]

Yes, plus Factory. The rest are VERY RARE!

[@redhotbits]

not a good explanation. design pattern is a solution to a recurring problem. if you dont have a problem you dont need a design pattern. nowadays everyone is obsessed with patterns even when there is no problem to solve