Personally I really enjoyed the video and the humor but because of the vulgarity I cannot share it with my students which I find disappointing. You did such good job of providing nice, succinct overviews of the patterns it would have made a great resource for them.
A cool thing happens if you learn programming by yourself: after some time you start to implement these patterns without knowing them formally. Most often they are more clumsy than the original but the spirit is there. Really cool how patterns are just a result of efficient and modular thinking.
The hope though is that you eventually learn the terms so that when a design is handed to you with just design patterns you understand what is going on.
@@edukee also true. At times you have to ask yourself if it is worth coding a whole embedded abstraction layer combined with high level OOP to turn on an LED just because somebody on youtube told you to. The boring but general answer is: there is no universal approach. Different applications require different styles.
🎯 Key Takeaways for quick navigation: 00:54 Creational *Pattern - Factory: Use a factory to instantiate objects like ordering a burger, specifying the type of object you want without worrying about its creation details.* 01:40 Creational *Pattern - Builder: For more control over object creation, use the builder pattern. It involves individual methods for adding components and a build method to create the final object.* 02:37 Creational *Pattern - Singleton: Ensure a class has only one instance. Useful for maintaining a single copy of application state with a static method to retrieve the instance.* 03:47 Behavioral *Pattern - Observer (Pub-Sub): Implement real-time updates by having a subject (e.g., UA-cam channel) maintain a list of subscribers and notify them of events. Subscribers implement an interface for event handling.* 05:24 Behavioral *Pattern - Iterator: Define a pattern for iterating through values in an object. Useful for simple arrays or more complex structures like linked lists.* 06:32 Behavioral *Pattern - Strategy: Modify or extend a class's behavior without changing it directly. Define strategies (e.g., filters) as implementations and pass them to the class at runtime.* 07:25 Structural *Pattern - Adapter: Make incompatible interfaces compatible. For example, create an adapter to make a micro USB cable fit into a standard USB port.* 08:34 Structural *Pattern - Facade: Use a wrapper class (facade) to abstract lower-level complexities, providing a simpler interface for programmers to interact with.* Made with HARPA AI
This was a good introduction! I will say, because they are the usually the most talked about, there are some things that are worth elaborating further on in regard to creational design patterns: Factories aren't just about fabricating objects. One of the big advantages is that they disconnect how an object is made from where it might be needed to be created. The best part of factories are that they can be instantiated and shared and passed between code. Otherwise, they're just a set of default constructors. They're often considered outdated because most languages have first class functional support these days. A function that takes no arguments and returns a new thing when called can usually be passed around. This is essentially the same as a factory. Builders aren't necessarily identified by their methods that can be easily chained. You can have builders that don't do this and they're still a builder. They're useful, like the factory, for when you have pass them around to other code. For example, you might have a lot of code that wants a say in how an object is created. It lets you spread the logic for how something is created over multiple places and build it once everything has had its input. It also lets the final result be immutable if you would prefer, making it mutable during creation and allowing for the resulting object to say "no more changes!" Singletons are great but hard to test. Best practice is to make a singleton extend some kind of interface class and provide the instance to the code that needs it, either as-is or via a factory. This lets you swap it out when you do testing. Otherwise, you're locked into always using that global state in your tests and it gets harder to work with!
@@jsvrs I still develop with Java (don't know how the Frontend came into your comment). But since 3 years I only develop Java as a hobby. 3 years ago I switched to develop professionally with a LowCode platform called OutSystems in my company and I love it!
Nice refresher. On the topic of GoF patterns, many of them may seem outdated or unnecessary for inclusion as patterns because for modern developers many of these patterns are even included at language level as basic features, however, it was much different back then when OOP was just taking off in enterprise world.
This! And also, a lot of GoF patterns are now outdated in most used languages thanks to multi-paradigm approach which include functional programming (where GoF is a base feature)
NeetCode is to coding to what The Organic Chemistry Tutor is to all school subjects, everything is clear and easy to understand when you guys teach it!!
Been putting off reading head first design patterns for a long time. This seems like an excellent intro to each concept that I can now find more references to
Personally, I don’t consider ‘Head First’ a good intro. Many examples in that book make little sense and descriptions are too verbose at times even for simplest terms. I’d suggest as an intro finding a retelling of that book as a course or video playlist.
tbh the book isn't really worth it, just like SOLID and "Clean Code" these things have been hailed as bibles when in most cases they only patch problems that are inherent to OOP. Or they make up problems and pretend to solve them (SOLID principles especially)
@@marcs9451 do you have any resources for better programming? ive been going down the rabbit hole of trying to learn the right concepts since ive gotten into c#. whereas my whole past has been nothing but functional programming. seems like everyone holds these couple of books religiously when they are outdated? so where does a developer start?
Knowing these patterns is only one side of the coin. What's more important is really understanding when (and when not!!!) To use them, especially in production code. I used to put singletons everywhere, feeling like a rockstar. And then, I learnt about SOLID and what can I say... In hindsight, singletons are a huuuuuge anti-pattern for all but the most edgy of the edge cases.
Basically, it really is only app state or no singletons at all - except if your app works with some kind of resources, such as device drivers, when wrapping the device client into a singleton is really important
@@wertrager sure, there are situations where wrapping something in a singleton is safer. But even If I absolutely have to use a singleton for some reason I would always stick to SOLID principles and pass the singleton instance using dependency injection instead of fetching it through the static class everywhere.
The facade reminds me of some subs/functions that I have in one of my libraries that are too dangerous to handle directly so I added safer wrapper subs/functions around it, which can each be used depending on the required features. It's also kinda like a factory, but not quite.
@@evyats9127 that is literally what youtube is, people building on eachothers styles and ideas, you’re not making a good or intelligently designed criticism
As you touched on with pub/sub for Observer patterns, naming can be an issue. As a developer with decades experience it can be a challenge when these patterns are “rediscovered” and given new names. This probably wouldn’t happen if people truly understood the patterns instead of memorizing the fancy name de jour for them.
My understanding is pubsub is different to observer. The distinction is that observer calls the listeners directly in code, so the listeners are guaranteed to receive the message. In pubsub it is separate programs communicating with each other, often on separate computers over a network. This means that in pubsub you need to think about how the subscriber should behave if it misses a message, this isn't a consideration for the observer pattern.
@@whossname4399 The same pattern, no networks involved, was described as event subscribers in the early days of event driven programming. If I recall the Borland OWL and maybe even Turbovision used these terms. It may be the terms are being refined over time to be more specific.
@@user-yr1uq1qe6y hmm. Another distinction is I've only really seen the observer pattern described in the context of heavily object oriented code (I've been working with mostly functional code for the last 5 years), where as I've mostly seen pubsub in the context of network communication. I can see how the two are similar, but they really seem like different things to me. I don't even know if I think of pubsub as a "pattern".
@@whossname4399 It’s been so long since I dove into the gof design pattern stuff that I looked up the observer pattern wiki. It mentions pub/sub as a component of the pattern. The distinction does seem to be somewhere in who owns the list of observers (subscribers). Wish the day job still allowed us to spend official time on this type of thing!
I use these but never really bothered to learn the formal definitions. Seems a bit dated in today's patchwork of random NPM libraries engineering, but still fun to finally link the names to the faces!
Having watched ArjanCodes and through years of coding experience - you could make your iterator "next" logic, @6:10, cleaner by doing an inverse check, like so: if not self.cur: raise StopIteration val = self.cur.val self.cur = self.cur.next return val
One great example od a Facade class that I insantly understood after is "gcc". You can assemble if you like with "as" or link with "ld" or "cpp" to see the macros expand, but you can just use "gcc" and get all of this done.
Appreciate you breaking it down so thoroughly while making it easy to understand! Remember working with a senior engineer who would talk about a few design patters he implemented but he couldn't always explain it effectively. This was very well done! Motivated to get back to learning these patters on my own now! Thanks!
Hey NeetCode, thanks for the succinct breakdown of these patterns. I am an engineer, but not a dev, and don't really use these patterns, but in areas such as IaC just as an example, it's interesting to think about how I could implement concepts introduced in these patterns. Loved your analogies so I could visualize these concepts better. Thanks!
Hello sir, I am looking for CS intership oportunity. My qualification are 9 cgpa (till 5th semester)skills DSA ,DAA, python(django, machine and deep learning), Java, HTML , CSS , JavaScript . I hope to hear from you soon.
Out of a sort of immaturity, I spent many years wasting time learning fundamentals the hard way with C of all languages (facepalm). I have a certain level of literacy from that, but now I have a lot of bad habits to unlearn. Python or perhaps JavaScript would have been the sane choice for many of the projects I worked on, upon reflection.
@@tldoesntlikebread relative to C, Python is higher level language. On the whole continuum of language, Python is still on the very low level side. More so, Python is deliberately low level, as it discourage constructing higher level abstractions as something "un-Pythonic". It is built around all the same structural control flow constructions as the other low level languages and does not allow defining your own control flow or abstracting away from the very notion of control flow. Higher level languages allow to build embedded domain-specific languages on top of them with an arbitrary level of abstraction. Python explicitly does not allow to do so and discourage even this way of thinking on ideological grounds.
Hahah 7:30, that subtle music along with the example, and then immediately giving another example saying "or maybe an example you're more familiar with", implying most programmers don't... ya know. Perfect.
This is really great stuff, I cannot tell you how much your videos have helped in solving questions while I am hunting jobs. The way you explain concepts with such intuitive examples is something I have not seen before. Please keep posting awesome content like this.
If only I could give this video more than just one like. After a whole life reading and studying these patterns, I finally understand them thanks to this video!
Laravel has a great implementation of the facade pattern. Basically, you can use it to statically proxy methods into any object, regardless of if it's a static or instance method. Super nice and simple.
@@Davidlavieri "the most utterly offenders" - Why would I take the coding preferences seriously of someone who can't construct a basic english sentence?
@@Davidlavieri separation of concerns often violates KISS and readability is somewhere in between, so there's a balance, and convenience patterns like Laravel's facades are very worthwhile in addition to serving the DRY principle effectively.
It was good that you disclosed your position in relation to JS, I can't trust no one that is align the madness of it! It's an important tool to know, but you don't have to love it.
The builder pattern is so interesting to me. The only reason for its existence that I can think of is that if you're working in a language that doesn't have language based solutions that make it easy to handle classes with many many parameters in their constructor, where a lot of them are optional or have default values. It's much easier to understand how to use the class by reading an example initialization that uses a builder pattern and only sets a few fields, compared to a constructor call of 10 elements where 7 of them are null. But if the language let me call constructors in a way that requires named parameters but also allows for optional parameters, I think the builder pattern loses its value.
True! Java and Kotlin are the perfect examples of both cases. But the builder pattern can teach you the mechanism behind it. And having a different construction syntax can open your mind to a different paradigm if you're observant enough. But I don't like having to implement it 😅
Worth noting that, in a language with singleton modules, one should usually use those instead of instantiating a class, as a singleton class is unintuitive and breaks assumptions one may have about classes
i think good idea is write this 8 patterns in language u work look at it when u start the problem and choose the best. This is the fastest way to larne it in my opinion :o
If the iterator pattern is implemented directly on the data structure like in this video, you can only iterate it once. Instead, ___iter___ should return a new ListIterator, and this ListIterator should have a ___next___ method
I think you should really have a good reason to use a pattern. The worst thing is having the wrong abstraction for the job. Too many times, people learn these pattern and just start randomly applying them everywhere. And before you know, everything is a abstract factory adapter strategy
🎯 Key points for quick navigation: 🍔 Factory Pattern: Create objects without specifying the exact class 🏗️ Builder Pattern: Create objects step-by-step 🔌 Adapter Pattern: Make incompatible interfaces work together 📢 Observer Pattern (Pub/Sub): Allow objects to subscribe to updates from other objects 🔁 Iterator Pattern: Access elements of an object sequentially 🧭 Strategy Pattern: Change an object's behavior at runtime Facade Pattern: Provide a simple interface to a complex system ♻️ Strategy Pattern: Change an object's behavior at runtime by passing strategies Adapter Pattern: Make incompatible objects work together (like an adapter for different plugs) Facade Pattern: Provide a simple interface to a complex system (hide complexity behind a simpler facade) Made with HARPA AI
Nice story linking. I guess why ppl forget the design patterns easily is due to lack of story to link them. Now it’s easier to remember Burger factory builder, or USB micro to mini adapter. And from this extract information.
“**presents incompatible screw/hole metaphor**, or maybe an example that you’re more familiar with…” - Brilliant 😂 Subscribed for the funny yet educative value, keep it up 👍🏼
This is a nice summary but it is missing a crucial detail for design patterns: WHY do you use each one? Or phrased differently: which problem does each one solve? Knowing that will make it a lot easier to know when to apply which pattern. Or even recognise that there is a more language idiomatic solution available
It's amazing. I really liked how easy and fun you taught about complicated concepts. Tbh, I need more explanation to understand some patterns though. I really appreciate it you made this video. Thank you very much!
Yet an another attempt was made to clear the mysterious design patterns. 😅 Good video. I was talking about this yesterday with my colleague. You forgot the most important one, the state machines. Then again, if you are not from embedded world, the state machine pattern aren’t that often used.
There is a difference between pubsub and observer pattern. In pubsub, the publisher doesn't know who the subscribers are but in observer pattern, list of observers are known to the observant
The more important distinction is that in pubsub subscribers aren't guaranteed to receive the message, so you need to handle what happens if the message isn't received
Yet with a transactional outbox approach, subscribers are guaranteed to "eventually" recieve the message at least once so it becomes about ensuring idempotence.
@@Wouldntyouliketoknow2 my experience with pubsub is with systems that send a few messages a minute, so my approach has generally been either ignore the missed messages if they don't matter anymore, or include a sequence number to detect missed messages and a mechanism for the subscriber to query any messages that it misses.
My ranking Factories: 6.5/10, used for hiding complexity, but I prefer builder. Builder: 10/10, perfectly simple, yet rich. I use this whenever I can. Singleton: 8/10, I use static instances all the time. Observer: 9/10, especially using events. Iterator: 10/10, stackable with other iterators (map, chunks, windows, etc.) and can downgrade to fori loops or lists. Strategy: 8/10, generally useful. Adapter: 9/10, great for filling gaps. Facade: 9/10, great when building up programs and ensuring safety, especially with unsafe/exceptional "Programmer must ensure" functions.
I understand these are essential data structures that developers need to understand, but the way in which OOP overcomplicates an idea as simple as having a function input to filter a list boggles my mind.
Its so funny how I really ace my theoretical cs classes but I could not learn how to develop a simple app with flutter after 1 year of trying. Of course there were breaks and so on but like when I had to code a dht in C within 2 weeks for uni I aced that too. But somehow my mind always core dumps when trying to do some app or web dev
Singleton does have some rare use cases, though ormally it is at least a code smell. Observer is the only one that is genuinely useful and not trivial or obvious.
i dont get that dig at java. anyway when i was learning the observer was the easiest for me to understand and the coolest, the most immediately useful for what i was doing. i was obsessed with it. most of other ones like the strategy i learned and didn't see the immediate use but eventually ended reinventing the wheel and only noticed i have implemented them already on repeated reading.
✅ In-depth OOP Design Patterns course: neetcode.io/courses/design-patterns
✅ OOP Interviews course: neetcode.io/courses/ood-interview
I love you..err I mean thank you
need more on functional programming tho
Loved Careless whisper. I say keep 'em coming!
Personally I really enjoyed the video and the humor but because of the vulgarity I cannot share it with my students which I find disappointing. You did such good job of providing nice, succinct overviews of the patterns it would have made a great resource for them.
I love the simple code expression to illustrate a rather abstract concept - pattern ❤ thank you for the great work.
A cool thing happens if you learn programming by yourself: after some time you start to implement these patterns without knowing them formally. Most often they are more clumsy than the original but the spirit is there. Really cool how patterns are just a result of efficient and modular thinking.
That is so true.
factory that builds factory is no surprise - design patterns have emerged for a reason, they're composable in that way.
The hope though is that you eventually learn the terms so that when a design is handed to you with just design patterns you understand what is going on.
This is me. Understanding how it works without even know the patterns have names
@@edukee also true. At times you have to ask yourself if it is worth coding a whole embedded abstraction layer combined with high level OOP to turn on an LED just because somebody on youtube told you to. The boring but general answer is: there is no universal approach. Different applications require different styles.
🎯 Key Takeaways for quick navigation:
00:54 Creational *Pattern - Factory: Use a factory to instantiate objects like ordering a burger, specifying the type of object you want without worrying about its creation details.*
01:40 Creational *Pattern - Builder: For more control over object creation, use the builder pattern. It involves individual methods for adding components and a build method to create the final object.*
02:37 Creational *Pattern - Singleton: Ensure a class has only one instance. Useful for maintaining a single copy of application state with a static method to retrieve the instance.*
03:47 Behavioral *Pattern - Observer (Pub-Sub): Implement real-time updates by having a subject (e.g., UA-cam channel) maintain a list of subscribers and notify them of events. Subscribers implement an interface for event handling.*
05:24 Behavioral *Pattern - Iterator: Define a pattern for iterating through values in an object. Useful for simple arrays or more complex structures like linked lists.*
06:32 Behavioral *Pattern - Strategy: Modify or extend a class's behavior without changing it directly. Define strategies (e.g., filters) as implementations and pass them to the class at runtime.*
07:25 Structural *Pattern - Adapter: Make incompatible interfaces compatible. For example, create an adapter to make a micro USB cable fit into a standard USB port.*
08:34 Structural *Pattern - Facade: Use a wrapper class (facade) to abstract lower-level complexities, providing a simpler interface for programmers to interact with.*
Made with HARPA AI
This was a good introduction! I will say, because they are the usually the most talked about, there are some things that are worth elaborating further on in regard to creational design patterns:
Factories aren't just about fabricating objects. One of the big advantages is that they disconnect how an object is made from where it might be needed to be created. The best part of factories are that they can be instantiated and shared and passed between code. Otherwise, they're just a set of default constructors. They're often considered outdated because most languages have first class functional support these days. A function that takes no arguments and returns a new thing when called can usually be passed around. This is essentially the same as a factory.
Builders aren't necessarily identified by their methods that can be easily chained. You can have builders that don't do this and they're still a builder. They're useful, like the factory, for when you have pass them around to other code. For example, you might have a lot of code that wants a say in how an object is created. It lets you spread the logic for how something is created over multiple places and build it once everything has had its input. It also lets the final result be immutable if you would prefer, making it mutable during creation and allowing for the resulting object to say "no more changes!"
Singletons are great but hard to test. Best practice is to make a singleton extend some kind of interface class and provide the instance to the code that needs it, either as-is or via a factory. This lets you swap it out when you do testing. Otherwise, you're locked into always using that global state in your tests and it gets harder to work with!
I'm a Java developer since 2008, and I LOVE your punches towards Java 😍 they are to much fun and true
Are you still Java frontend developer?
@@jsvrs I still develop with Java (don't know how the Frontend came into your comment). But since 3 years I only develop Java as a hobby.
3 years ago I switched to develop professionally with a LowCode platform called OutSystems in my company and I love it!
Nice refresher.
On the topic of GoF patterns, many of them may seem outdated or unnecessary for inclusion as patterns because for modern developers many of these patterns are even included at language level as basic features, however, it was much different back then when OOP was just taking off in enterprise world.
yep, this mostly seems like a nice tutorial about history times
Yes, but I guess it's still valuable to be able to learn the concepts and understand them
This! And also, a lot of GoF patterns are now outdated in most used languages thanks to multi-paradigm approach which include functional programming (where GoF is a base feature)
NeetCode is to coding to what The Organic Chemistry Tutor is to all school subjects, everything is clear and easy to understand when you guys teach it!!
Been putting off reading head first design patterns for a long time.
This seems like an excellent intro to each concept that I can now find more references to
Personally, I don’t consider ‘Head First’ a good intro. Many examples in that book make little sense and descriptions are too verbose at times even for simplest terms.
I’d suggest as an intro finding a retelling of that book as a course or video playlist.
tbh the book isn't really worth it, just like SOLID and "Clean Code" these things have been hailed as bibles when in most cases they only patch problems that are inherent to OOP. Or they make up problems and pretend to solve them (SOLID principles especially)
@@marcs9451 do you have any resources for better programming? ive been going down the rabbit hole of trying to learn the right concepts since ive gotten into c#. whereas my whole past has been nothing but functional programming. seems like everyone holds these couple of books religiously when they are outdated? so where does a developer start?
Knowing these patterns is only one side of the coin. What's more important is really understanding when (and when not!!!) To use them, especially in production code.
I used to put singletons everywhere, feeling like a rockstar. And then, I learnt about SOLID and what can I say... In hindsight, singletons are a huuuuuge anti-pattern for all but the most edgy of the edge cases.
Basically, it really is only app state or no singletons at all - except if your app works with some kind of resources, such as device drivers, when wrapping the device client into a singleton is really important
@@wertrager sure, there are situations where wrapping something in a singleton is safer. But even If I absolutely have to use a singleton for some reason I would always stick to SOLID principles and pass the singleton instance using dependency injection instead of fetching it through the static class everywhere.
@@arminmatthes ofc
The facade reminds me of some subs/functions that I have in one of my libraries that are too dangerous to handle directly so I added safer wrapper subs/functions around it, which can each be used depending on the required features. It's also kinda like a factory, but not quite.
It's great that u tried to make it more like the fireship videos ✌️
What is great about trying to mimic the style of others?
Yesh it's just like @fireship. I'm happy both of my fav channels are coming together 😂🔥(entertainment and learning)
@@evyats9127 so design patterns should only be used by the GoF dudes? We can’t follow their design patterns? 💀
@@evyats9127 that is literally what youtube is, people building on eachothers styles and ideas, you’re not making a good or intelligently designed criticism
Fireships videos are not very educational and way too memey imo.
As you touched on with pub/sub for Observer patterns, naming can be an issue. As a developer with decades experience it can be a challenge when these patterns are “rediscovered” and given new names. This probably wouldn’t happen if people truly understood the patterns instead of memorizing the fancy name de jour for them.
My understanding is pubsub is different to observer. The distinction is that observer calls the listeners directly in code, so the listeners are guaranteed to receive the message. In pubsub it is separate programs communicating with each other, often on separate computers over a network. This means that in pubsub you need to think about how the subscriber should behave if it misses a message, this isn't a consideration for the observer pattern.
Just saw the code. This looks like the observer pattern, not pubsub to me.
@@whossname4399 The same pattern, no networks involved, was described as event subscribers in the early days of event driven programming. If I recall the Borland OWL and maybe even Turbovision used these terms. It may be the terms are being refined over time to be more specific.
@@user-yr1uq1qe6y hmm. Another distinction is I've only really seen the observer pattern described in the context of heavily object oriented code (I've been working with mostly functional code for the last 5 years), where as I've mostly seen pubsub in the context of network communication. I can see how the two are similar, but they really seem like different things to me. I don't even know if I think of pubsub as a "pattern".
@@whossname4399 It’s been so long since I dove into the gof design pattern stuff that I looked up the observer pattern wiki. It mentions pub/sub as a component of the pattern. The distinction does seem to be somewhere in who owns the list of observers (subscribers). Wish the day job still allowed us to spend official time on this type of thing!
This makes more sense than the semester long course I had on design patterns
Ikr, I wish this video was here when I was studying in uni.
He legit one of the best to do it when it comes to explaining these type of problems. How google rejected this man once is beyond me
You had a course on design patterns wtf
I use these but never really bothered to learn the formal definitions. Seems a bit dated in today's patchwork of random NPM libraries engineering, but still fun to finally link the names to the faces!
Having watched ArjanCodes and through years of coding experience - you could make your iterator "next" logic, @6:10, cleaner by doing an inverse check, like so:
if not self.cur: raise StopIteration
val = self.cur.val
self.cur = self.cur.next
return val
Please never stop making videos. You have a gift for teaching. Your S-tier ability to explain topics is amazing.
Analogies are on point. Great work.
Thanks man you explained it so well I am never gonna forget. Please keep posting videos like this. 👍
One great example od a Facade class that I insantly understood after is "gcc".
You can assemble if you like with "as" or link with "ld" or "cpp" to see the macros expand, but you can just use "gcc" and get all of this done.
Appreciate you breaking it down so thoroughly while making it easy to understand!
Remember working with a senior engineer who would talk about a few design patters he implemented but he couldn't always explain it effectively. This was very well done! Motivated to get back to learning these patters on my own now! Thanks!
Oh, we defiantly need a course on deign patterns from you
Hey NeetCode, thanks for the succinct breakdown of these patterns. I am an engineer, but not a dev, and don't really use these patterns, but in areas such as IaC just as an example, it's interesting to think about how I could implement concepts introduced in these patterns. Loved your analogies so I could visualize these concepts better. Thanks!
Hello sir, I am looking for CS intership oportunity. My qualification are 9 cgpa (till 5th semester)skills DSA ,DAA, python(django, machine and deep learning), Java, HTML , CSS , JavaScript . I hope to hear from you soon.
@@nevdread1488 I will never take an Intern that spams public comment sections
@@TragicGFuel Lmaoo
Love the video, wish it was using a lower level language than python so you can really see how things are working behind the scenes
If I hadn't already subscribed, that "Please" at the end would have sold me. The content was good, too.
As someone who is going through the basics of Python, I'm pleased to see how much easier it is to play with data structures
It's pretty hard to do more high level than python without straight up switching to English or something like that
Out of a sort of immaturity, I spent many years wasting time learning fundamentals the hard way with C of all languages (facepalm). I have a certain level of literacy from that, but now I have a lot of bad habits to unlearn. Python or perhaps JavaScript would have been the sane choice for many of the projects I worked on, upon reflection.
@@w花b huh? Python is a low level language.
@@vitalyl1327 I'm pretty sure it's a high-level language, C is a low-level language, afaik they use C/C++ for some libraries in Python.
@@tldoesntlikebread relative to C, Python is higher level language. On the whole continuum of language, Python is still on the very low level side. More so, Python is deliberately low level, as it discourage constructing higher level abstractions as something "un-Pythonic". It is built around all the same structural control flow constructions as the other low level languages and does not allow defining your own control flow or abstracting away from the very notion of control flow.
Higher level languages allow to build embedded domain-specific languages on top of them with an arbitrary level of abstraction. Python explicitly does not allow to do so and discourage even this way of thinking on ideological grounds.
Hahah 7:30, that subtle music along with the example, and then immediately giving another example saying "or maybe an example you're more familiar with", implying most programmers don't... ya know. Perfect.
This is really great stuff, I cannot tell you how much your videos have helped in solving questions while I am hunting jobs. The way you explain concepts with such intuitive examples is something I have not seen before. Please keep posting awesome content like this.
If only I could give this video more than just one like.
After a whole life reading and studying these patterns, I finally understand them thanks to this video!
yeah you can, by creating multiple accounts lol
Laravel has a great implementation of the facade pattern. Basically, you can use it to statically proxy methods into any object, regardless of if it's a static or instance method. Super nice and simple.
facades are the most utterly offenders when it comes to shitty code
@@Davidlavieri "the most utterly offenders" - Why would I take the coding preferences seriously of someone who can't construct a basic english sentence?
@@Refresh5406 Maybe because english is the second language of a lot of people?
@@Davidlavieri separation of concerns often violates KISS and readability is somewhere in between, so there's a balance, and convenience patterns like Laravel's facades are very worthwhile in addition to serving the DRY principle effectively.
It was good that you disclosed your position in relation to JS, I can't trust no one that is align the madness of it! It's an important tool to know, but you don't have to love it.
This is a really nice video, well worth subscribing to this channel for. I hope you turn this into a series and cover more patterns in the future.
Love the vid! Much more concise than my CS Object Oriented class
The builder pattern is so interesting to me. The only reason for its existence that I can think of is that if you're working in a language that doesn't have language based solutions that make it easy to handle classes with many many parameters in their constructor, where a lot of them are optional or have default values. It's much easier to understand how to use the class by reading an example initialization that uses a builder pattern and only sets a few fields, compared to a constructor call of 10 elements where 7 of them are null. But if the language let me call constructors in a way that requires named parameters but also allows for optional parameters, I think the builder pattern loses its value.
True! Java and Kotlin are the perfect examples of both cases. But the builder pattern can teach you the mechanism behind it. And having a different construction syntax can open your mind to a different paradigm if you're observant enough. But I don't like having to implement it 😅
This is the best and simple explanation I've seen for design patterns, gg
you're great at teaching thank you for letting me brush up on my knowledge of these things
Worth noting that, in a language with singleton modules, one should usually use those instead of instantiating a class, as a singleton class is unintuitive and breaks assumptions one may have about classes
I’ve been watching videos like this for a while and a lot of it goes over my head. What should we learn first so these videos make more sense?
Awesome explanation! This is a life-saver when it comes to quick brush before the interview! 😄Thank you so much for making this video!
i think good idea is write this 8 patterns in language u work look at it when u start the problem and choose the best. This is the fastest way to larne it in my opinion :o
Not only every developer, but also everyone on the earth should know!!!
Bonjour and many thanks for the video. Crystal clear, straight to the point, fun... Nothing to say except merci!
These examples are easy to digest and understand, great video
Me: open video about patterns
UA-camr: js was a misstake
Me: close the video and open book about patterns
If the iterator pattern is implemented directly on the data structure like in this video, you can only iterate it once.
Instead, ___iter___ should return a new ListIterator, and this ListIterator should have a ___next___ method
Nah, i just programm how it comes (i programm in JS btw)
Cool video! Jokes and examples made it more easy to understand
9:25 thanks a lot for sharing the catalog of other courses too 😃😉
Amazing that most programmers already implement most of these patterns without actually learning it. They just make sense! 😅
Im learning MVVP with C# wpf. That's awesome
I think you should really have a good reason to use a pattern. The worst thing is having the wrong abstraction for the job. Too many times, people learn these pattern and just start randomly applying them everywhere. And before you know, everything is a abstract factory adapter strategy
🎯 Key points for quick navigation:
🍔 Factory Pattern: Create objects without specifying the exact class
🏗️ Builder Pattern: Create objects step-by-step
🔌 Adapter Pattern: Make incompatible interfaces work together
📢 Observer Pattern (Pub/Sub): Allow objects to subscribe to updates from other objects
🔁 Iterator Pattern: Access elements of an object sequentially
🧭 Strategy Pattern: Change an object's behavior at runtime
Facade Pattern: Provide a simple interface to a complex system
♻️ Strategy Pattern: Change an object's behavior at runtime by passing strategies
Adapter Pattern: Make incompatible objects work together (like an adapter for different plugs)
Facade Pattern: Provide a simple interface to a complex system (hide complexity behind a simpler facade)
Made with HARPA AI
Java code is usually over engineered to the point where spagetti code would be easier to understand.
this channel is gold.
Nice story linking. I guess why ppl forget the design patterns easily is due to lack of story to link them. Now it’s easier to remember Burger factory builder, or USB micro to mini adapter. And from this extract information.
nice and simple explanations! I love that you use python examples. I finally grokked the strategy pattern.
“**presents incompatible screw/hole metaphor**, or maybe an example that you’re more familiar with…” - Brilliant 😂 Subscribed for the funny yet educative value, keep it up 👍🏼
Today I watched your video for the first time... I understood maybe 12% of it. Hopefully, next time I watch I'll retain more
This is a good video. I want to distribute it throughout our company, however if at all possible, can you create 1 using C# instead?
@@ghost_mall You're not wrong, but not all developers are equal, hence the request for something in C#
This is a nice summary but it is missing a crucial detail for design patterns: WHY do you use each one? Or phrased differently: which problem does each one solve? Knowing that will make it a lot easier to know when to apply which pattern. Or even recognise that there is a more language idiomatic solution available
It's amazing. I really liked how easy and fun you taught about complicated concepts. Tbh, I need more explanation to understand some patterns though. I really appreciate it you made this video. Thank you very much!
Yet an another attempt was made to clear the mysterious design patterns. 😅
Good video.
I was talking about this yesterday with my colleague. You forgot the most important one, the state machines. Then again, if you are not from embedded world, the state machine pattern aren’t that often used.
There is a difference between pubsub and observer pattern. In pubsub, the publisher doesn't know who the subscribers are but in observer pattern, list of observers are known to the observant
The more important distinction is that in pubsub subscribers aren't guaranteed to receive the message, so you need to handle what happens if the message isn't received
Yet with a transactional outbox approach, subscribers are guaranteed to "eventually" recieve the message at least once so it becomes about ensuring idempotence.
@@Wouldntyouliketoknow2 my experience with pubsub is with systems that send a few messages a minute, so my approach has generally been either ignore the missed messages if they don't matter anymore, or include a sequence number to detect missed messages and a mechanism for the subscriber to query any messages that it misses.
ex. of adapter was so good for understanding.
Yeah, even music added :)
2:20 I knew you could use the backslash to extend if statements more than one physical lines but I did not know you could use it in this way too.
I felt I was watching Fireship video because of the thumbnail and how you delivered
Man, this is just pure masterpiece
"... faster than you can say 'JavaScript was a mistake'".
Hammered the like button right then. :)
My ranking
Factories: 6.5/10, used for hiding complexity, but I prefer builder.
Builder: 10/10, perfectly simple, yet rich. I use this whenever I can.
Singleton: 8/10, I use static instances all the time.
Observer: 9/10, especially using events.
Iterator: 10/10, stackable with other iterators (map, chunks, windows, etc.) and can downgrade to fori loops or lists.
Strategy: 8/10, generally useful.
Adapter: 9/10, great for filling gaps.
Facade: 9/10, great when building up programs and ensuring safety, especially with unsafe/exceptional "Programmer must ensure" functions.
Great video. Super clear. Got me to sub. I'll be observing what you pub.
Please make a video for other design patterns too like command pattern
Ngl this explanation was incredible
Awesome video using real day to day example that anyone can understand. I especially like the burger analogy.
best explanation of design patterns
thank you
builder pattern is goated
Very nicely laid out. Awesome vid
You never cease to amaze your viewers. Fantastic !!!
I like the way you explain things with examples, Your are dope bro, also use of funny and meme btw videos keeps users active :). Love from India 💌
This is valuable . Are there more popular Design patterns not in this list ?
on point careless whisper!! 7:30
I understand these are essential data structures that developers need to understand, but the way in which OOP overcomplicates an idea as simple as having a function input to filter a list boggles my mind.
Definitely agree
Of course I will subscribe. What a better thing do I have to do? Thanks
Its so funny how I really ace my theoretical cs classes but I could not learn how to develop a simple app with flutter after 1 year of trying. Of course there were breaks and so on but like when I had to code a dht in C within 2 weeks for uni I aced that too. But somehow my mind always core dumps when trying to do some app or web dev
Very interesting never encountered design systems before
That was very nice! It remembers me some ways to do things in OOP :D
I'll definitely recommand this vidéo to my students!!
Wow, you're an incredible teacher
7:34 was a nice example 😁
Thank you very much for this awesome video! Could you please do a video on dependency injection design pattern? Thank you!
I think it is important to mention that Singleton is an anti-pattern, as well as some other "patterns" shown in the video.
Singleton does have some rare use cases, though ormally it is at least a code smell. Observer is the only one that is genuinely useful and not trivial or obvious.
Clear. Concise.
What a great and simple to understand video! Thank you
I’ve learned more from this video than I did it my entire community college😢
this feels like fireship
I love him, so I appreciate this comment
You earned a subscription
This was great, subscribed!
i dont get that dig at java. anyway when i was learning the observer was the easiest for me to understand and the coolest, the most immediately useful for what i was doing. i was obsessed with it. most of other ones like the strategy i learned and didn't see the immediate use but eventually ended reinventing the wheel and only noticed i have implemented them already on repeated reading.
opening with the pimp my ride meme - LEGENDARY
This is fantastic. Please keep making more videos.
great video, I learned ALOT
Very useful, thanks!
PEP-8: Method names and instance variables:
"lowercase with words separated by underscores as necessary to improve readability."