Lol, I'm studying design patterns after studying some functional programming and this is what I just realised. Strategy pattern == first class functions, visitor pattern == pattern matching!
Reasons I find these react type videos to be among the top best things to be happening to my career: 1) I find out amazingly informative tech TH-camrs from the original videos 2) Primes constant interjections is basically 100x-ing the information 3) He’s so f*in funny. 4) This kind of gold only seems to flow from highly technical senior engineers in the creamy layer of companies Thanks prime, continue to make these !
No offense to prime, and he's about as good an engineer as it gets. People that write business apps adopt the OO things because its useful in that context. engineering for large scale isn't the right context. I know people making $300k a year building salesforce apps, and $300k a year building large scale streaming systems. Context.
That's how the whole "patterns" thing started... a bunch of 4 guys were just trying to codify good ideas they'd seen so they could share them around. Things then... well. Things got a little out of hand. MyClassFactory myClassFactory = new MyClassFactory(); MyClass myClass = myClassFactory.create(); BWA HA HAH AHA HAHAH AHAH AHAAA
I remember being asked which patter is a smart pointer in c++. I listed 3, before they told me it was a proxy and i was like yeah, i guess, but who cares?
8:08 Well, as an avid Python programmer, I can vouch that while using decorators feels pretty nice (most of the time), writing them is an absolute mind numbing experience.
@@ShadowKestrel I'm doing the proc_macro workshop and doing the derive(Builder) macro as my first 1 since yesterday. It's all fun and games, till I got to the optional-field part. I shudder at the realization that there are so many way to make a struct field optional and I would need to check all of them. I'm just starting out with it so there are without a doubt tons of pattern and tools to help with these kind of things that I don't know of. Although do think it's probably a very useful tool to have in my arsenal and way more powerful than macro_rules.
how a decorator works: you write a function that takes in a function and gives back the "same" function plus you can do code on the side def print_instead(func): return print will give you a decorate that replaces the decorated function with print :D
I too love the strategy pattern. Higher order functions are the most beautiful way to do the strategy pattern. Functional programming is just the strategy pattern all the way down. I love the strategy pattern btw.
i was a bit confused at the begining of your message - does he rly love the strategy pattern, but at the end I put aside my doubts - you DO LOVE STRATEGY PATTERN!
It would be cool to go through examples of patterns in rust. I haven't looked at the code for serde but it seems to use interesting patterns such as adapters to support different serialization formats.
Builder is my favourite. You can omit and add whatever you want, the depth and detail that you ask of the struct is (USUALLY) directly paired with the amount of chaining you do. You can go with defaults, specify a few parameters, add more if you need to, or you can do the equivalent of in-place initialisation (which although it may not be as performant unorganized unoptimised, compilers might recognise the simplicity of the chained functions and would be able to evaluate the code into an object literal).
TH-cam REALLY wanted me to watch this, popping up on my end screens and recommended list for like 2 weeks now. I finally watched it..... sadly I'm not far enough on my coding journey to have learned anything or understood what was going on other than the great Prime jokes🤣
I use the builder pattern for all my JS Web Components. I am surprised people are surprised at returning this. It works nicely with a functional style, too, with a builder class whose final commit returns a DOM node and other methods return this. The web component then basically builds as one function call that when returned returns the ready component. You may get away with using not a single if else for a full and fully parametrised component with ES6 if returning this from each build method except commit. Listeners and any other features are just properties inserted with the builder as each sub component is described by joining build calls with the dot notation. The build tree will thus extrapolate to any complexity, as a component can always comprise any of the builds, which can comprise any builds, and so on, till the call stack returns to the top level and a full HTML component with any child components is returned, and is inserted in the DOM with the final commit. In theory, the whole web page could be built thusly. Prettier than some React stuff I have seen.
the idea of patterns is great. how people found patterns and tried to put everything in a pattern shaped hole was not. specially when "patterns" became some sort of bizarre synonym of OOP
Some of the patterns are so ubiquitous that you almost don't need to know them. Like I don't need to know that air is called air because I just breathe it naturally
I'm just about to suggest in my project to start using a Factory for a single reason. We have 5 different classes that create the same object using a builder BUT it isn't clear how many fields of that class have to be set up(spoiler all of its parameters so always the complete builder). To isolate in a single place how the creation of that object has to be, enforce validations and ensure one of the fields that is a map is always created correctly depending on 1 of those 5 usecases. If not we will snowball into having distribuited the creation logic across multiple places
And *that* is what factories are made for. To unify and hide away complexity from the developer who shouldn't have to worry about that stuff, and you still need to have some unified way to create everything. Oh, and I dislike factories (honestly not too keen of builders either) so I have every reason to absolutely shit on them. It's just that in some cases they actually do make sense. They are simply abused to infinity and beyond.
@@CottidaeSEA i feel like this how it goes for a lot of patterns. We hate them because of how they get misused, but by god they are very useful in their actual niche.
don't use a builder or factory if instantiation params are wonky/unknown. you should consider writing a context object. then any methods/classes that have the wonky/painful params pull from a single source. you'll see this a lot in JS when working with large libraries. There will usually be a single settings object which describes how the library should behave. The key to keeping settings objects maintainable is making them immutable. Once you allow mutations to settings, you are no longer passing around context, you are passing around state. immutable context is predictable state is not.
I usually think about the Facade pattern in terms of delineation between groups of developers, or major functions in an app... But one could just consider it a part of UX (or DX) → You make stuff easier to communicate, understand, and use. I wouldn't think of it normally as an endpoint though - unless you were explaining the endpoint with docs in a "This is all you need to know to do this" sense. But I think that perspective comes from seeing Facades as typically being a class with clear features, and not just any point that simplifies interactions between one system and other systems.
Common confusion: Observer is not Pub-Sub. Observers listen directly to their Observables/Subjects, so then each Observable/Subject must keep references to all of its Observers and become bound to their lifetimes. Publish-Subscribe adds one more level of indirection by having publishers and subscribers both depend directly upon a Channel between them; therefore they are tied to the lifetime of the channel rather than each other. Subscribers only become aware of publishers when notified with a message that provides the reference to the publisher if necessary.
Observer, Iterator and Strategy are great. Singleton is ok if you're careful with state (Rx singleton Observable for instance). Adaptor and Facade are unavoidable, but I hate how coupled they can get. Factory and Builder are meh - I feel they're needed sometimes but they get overused. ps. lol at Primer reacting to Python OOP in real time
Saw the original before, generally good comments as far as my experience with these patterns go. One critique I have is your statement that "Everything is a facade, becaus you hide information" with something something private. Facade does obfuscate variables and functions from the programmer, but they are still accessible from the outside. Basically, Facade (at least as stated in the GangOf4) is an interface to a functionality that says "Hey, 99% of the time, you will want to use me by calling these couple of functions here. If you need more custom behaviour and you REALLY know what you are doing, you can also tweak all my other variables and use these other functions". So Facade gives you a set of convenient functions to use it with, but also allows for access to everything else about the interfaved functionality, if you want to.
The only reason to use a factory is to hide the complexity of object creation. If a design pattern does not result in simpler code, then you are using the wrong design pattern.
Builder and factory are just semantic variations on a constructor. Builder just turns parameter assignments into individual functions that can be chained together.
I think the Singleton pattern as just a special case of "execution contexts" where there is only one global context. It can simplify code by removing the need to explicitly pass down dependencies into the callstack. However, as with all static globals, it creates global coupling. staying with the python example from the video I would always rather use a construct as below instead of a singleton: ```python with some_context_of_type_y(): with some_context_of_type_x(): foo() def foo(): y = get_y_object() x = get_x_object() ``` IMHO it gives better composability on the outside scope and has the same advantages as singletons on the inside scope.
Yea there are very few scenarios to actually use this pattern once you have DI, in fact it only interferes with/breaks DI. The only two examples I can think where I would actually use it are A) a tiny app where I'm not going to include an IoC library or B) In the very initial boot of your app when the IoC container/AppContext is either half constructed or has not finished initializing and is in an unsafe/incomplete state, yet you still need access to critical components like a preInit logger. Cause if AppContext fails to initialize... and that's where you get your logger from... and you want to log the error... and it IoC fails to initialize.... so you want to log it... but it has the..... wait.. where was I? where am i? WHO ARE YOU PEOPLE???? Can someone call my mom, im scared
Reactive programming works a lot with Observer, Iterator and Strategy patterns. For some historical insight, it's called RX because Microsoft did a lot of work with something called Reactive eXtensions, hence it evolved to RXJava.
Peak of OO culture: Implementing Strategy and Visitor patterns (I still can't implement the visitor pattern without looking it up). Peak of FP culture: Monad transformers
@@wlockuz4467 SIMPLIFIED: it's a "wrapper", which takes closures/functions/lambdas which modifies the internal data (aka map function) It also needs a "pure/unit/wrap" function and also a bind/flatmap function. *Example without monads:* let person = Person { name: "John" }; function print_name(person: Person) { if person != null { if person.name != null { print(person.name) } } } print_name(person); *Example with a monad (Option):* let person = Person { name: "John" }; function print_name(person: Option) { person.map(p -> p.name).map(name -> print(name)); } print_name(person);
@@wlockuz4467 Instead of getting the data and applying your code to it (like a loop), you pass your code to the monad an IT will apply your code to the data. You just don't exactly know if, how or when cuz abstraction, which is the entire point. For example, in an Option/Maybe/Try monad your code will only be applied to the data if it exists.
outside of Monad Transformers you have MTL, Lenses and for many types of programs instead of using MTL many people use Freer Monads/Extensible Effects. Also arrows
I used to dislike decorators, but I'm currently working in C# (which doesn't have them) and I keep running into instances where it would be really nice... I have a class that makes API calls asynchronously, but I need to limit the number of async calls being made at a time. So, I need to use a semaphore to force threads to await if all the other threads have used up the semaphore. Would be super nice to just use a decorator at the top of every method that makes an API call so that it wraps the execution with an await to the semaphore, but not an option for vanilla C#. I ended up creating another class called RequestExecutor that has methods that take lambda functions and do this instead, but it feels less clean.
@@banatibor83 If you think decorators are bad, what about the abstractfactory patterns here. They are used for black-box aspect oriented programming to simplify your code, and are in JavaScript as well.
Great comment at 15:48 . From a functional perspective, the "interface" you are crying out for, is just a function. However I don't think it's worth a full fedora-tip here, because as competent engineers we need to be prepared for any situation we may walk into. Such as George Clooney walked into in From Dusk Till Dawn.
Ngl... sometimes listening to the definitions of these named patterns,I feel like the next one is gonna be "and the Typing Pattern is where you press keys on the keyboard to put code in a computer!" "The Press Play Pattern is where you have to click a button to make your code run after it's written!"
I am convinced that the US has a different Java than the rest of us. The only place I know of that has abstract factories are frameworks like Spring. Because Spring can make a case for "I need to have a way of producing objects of whatever type specified", as well as "and I need to allow more than one way of doing it". And that's just because of the very generic way the IoC-container works.
2:48, they just gave a name for a thing that has been made in C for decades: struct CheeseBurger { const char *ing_1, *ing_2, *ing_3 }; #define createCheeseBurger CheeseBurger { "bun", "cheese", "beef-patty" } And then call it by: CheeseBurger a_cheese_burger = createCheeseBurger; 5:20, this is a "lesser version" of C++ for 2 reasons: a) If 1 just wants to customize the initialization, C/C++ way is much better, as exposed above, due to compact syntax. b) If the goal is to customize it along the way, not only on initialization, it should has a control of which f() is allowed do that - _and it seems that only C++ has this feature_ . Otherwise, all sorts of bugs can come from it, because everything will be public, which is the worst nightmare, depending on the project complexity. 10:57, why use an interface for that? Couldn't it be just a class? 16:00, again, why an interface? This thing is awkwardly slow! 21:00, and that's why f() programming < OO: the 1st lacks good facades. In C, you can let that memory management "encapsulated" away in a different file. But there are issues: a) Each file like this will be dedicated to each object, which hurts scalability. b) If only 1 generic file like this is created, then the user will has to keep traveling alongside with that array, which is exposed to dumb mistakes for long unnecessary time. It's still possible to create several macros, trying to hide that array exposure, but it's still a precary solution.
This video was good. Why? We learnt something, unlike some videos where you just rant or do irrelevant optimisations, in this I actually learnt something which can get someone hired.
As a netflix btw guy Prime could/should have really said a bit more about the observer pattern. ReactiveX was a live changer for me, and that netflix talk about it sold it to me, back then.
Close your eyes and listen and you half expect Prime to throw out a random "Morty" during his speeches. Y'ALL KNOW I'M RIGHT (seriously though if Prime wasn't a software dev he could probably take over for Rick's VA)
Thanks for going over this. I feel like I must be missing something because I’ve watched this and Fireship’s video on it and feel like this doesn’t actually help me think about the way data can be structured or organized. I’m a high school teacher, so working on learning to relay the lessons to students in my CS classes. Thanks Prime. 😊
The main idea is to not reinvent the wheel every time a similar problem occurs. Back when the book came out, the idea was that software engineering was a relatively new discipline in comparison to e.g. engineering or architecture. So they started to look for standard solutions in patterns at the design or implementation stage of a project
@@spittylama Thank you. I do understand that’s the *purpose*; I’m saying I can tell I still have yet to understand the content. I have been working on building projects with data, but I’m not sure I see the patterns, yet. I hope that makes sense.
It's funny how the borrow from the French language lost the cédille, but kept the pronounciation : it's façade in French, where ç is pronounced like double s
The implementation of the linkedlist iterator in the video is actually faulty. If you would create two iterators they would actually both modify the object.
The idea of a factory is to provide only one interface create so client class could use it to create object of given interface. Like when you need some default value (like in data classes) when constructing object.
The factory pattern for this isn't needed you can just do this: Burger.Vegan = lambda **kwargs: Burger(ingredients=['special sauce', 'salami'], cook=lambda: Grill(temp=50, **kwargs), **kwargs)
12:50 i had the similar experience. Microsoft tried to hire me with a 40% cut of my city salary. They said oh but we do value you, we intend to hire you out to clients for $5000 a day. This was in 2000 when $5000 was still quite an impressive amount.
Builder isn't "better" than factory, they are just suited to different circumstances - builder for flexibility; factory for simplicity. E.g. a library class uses builders in order to provide maximal functionality, but an app using that library wraps this in a factory to provide a simpler interface for the small number of specific uses its needed for in that app.
I just tend to find that factories are not what I want, yet. That's what I find myself doing. But a builder almost universally is what I want. Oftentimes you can even interchange them and I find the results almost always better with builder and a good setup defaults
Design patterns in functional programming: strategy pattern: functions builder pattern: functions observer pattern: functions adapter pattern: believe it or not also functions
9:50 "shared mutable state is the bane to all programming and the key to super awesome amazing performance and it is the scariest thing in the universe...so...careful."
As a Java developer I stay away from factories if I can. But yes, I've had my share of Complicators on teams. And yes, (fluent) builders to create immutable instances ❤
11:00 Yeah, yeah, but there are languages *cough* where managing the lifetimes of the subscribers kept in the list can cause you a lot of trouble, and even using smart pointers might not save your day in cases where certain strange runtime dependencies in the destructors cause race condition or some runaway loops or similar fun. And yes, Facade is not an actual pattern of it's known, it's only a special case of the Wrapper.
It is only useful when you need to control what actually gets instantiated or how it gets configured during or after constructing. In all other cases, just doing a "new" of the proper class is both simpler and easier to follow. So if there is this need, sure, go for it. But I will never consider it a pattern to default to.
Primogen really souds like a young Rick, from Rick and Morty. I dont have time for making this but just close your eyes and imagine it. Add some burps and voila. I think its the rhythm.
On the last point of the facade pattern, NeetCode says "you don't want to think about memory allocation" and here I'm thinking "it isn't difficult at all, there is this thing called realloc." The only reason why it sucks in java is because java does precisely this, remove any need for you to think about memory allocation. Realloc is a better abstraction than java.
The main difference is if there's a varying amount of options when building an object. Say that I'm a really weird person and only want a burger with only a bun (no patty or cheese). Then I can use burger = BurgerBuilder().addBun().build() Or if I only want bun with cheese (no meat), burger = BurgerBuilder().addBun().addCheese().build() Otherwise you'd need several different constructors to handle every possible combination (which quickly gets messy when multiple options are involved.) The burger example is not the greatest to show this difference but hopefully that made some sense
the code is in Python but you used the new keyword hahah. You don't need builder in Python cuz of default arguments, keyword arguments and dicts in Pythons.
8:00 No, if used like this, singeltons are pretty stupid. I just use them when I can't have global state, or I don't have control over the main function or something similar. (only in Unity) And I never define a static method when using them. I just use a public static parameter, or different static methods to access it.
I did use a factory on my own. Needed to make a bot object that needed to load a few things from files assorted with a user Id. It was actually a ton of fun
I usually prefer default in Rust over the builder pattern. I do emit part of this is because it's a lot easier to implement. I don't normally mind using the builder pattern but I hate programming it. Also I feel like it doesn't normally have much of a benefit so I don't know if it's worth implementing in most cases.
Singletons are fine if they contain no mutable state. At my work we use singleton lifetime DI extensively because all state is passed through arguments and returns. Classes become modules and interfaces make those modules loosely coupled. It's almost like functional programming but with a nicer syntax.
Why not just use a static class then? Genuinely curious the difference between a singleton and a static class, I'm sure they are drastically different I just don't know how.
@@grantpeterson2524 In javascript and python there is a memoize (called lru_cache) method that caches calls for functions, the memoization of a no argument function is called the singleton. Static classes run code at the start of your program, while singletons are initialized the first time they are used.
Facade is not even a pattern, it is a higher level architectural decision. I use strategy, iterators, PubSub and builders all the time. They are second nature. I also use decorators a lot. IMHO they are almost magical, especially when coupled to strategy patterns. Patterns that blew my mind are Command, Visitor and bridge pattern.
I almost spit out my granola at this comment: "code review feedback: 'more façade'" sounds like a good "-10x" strategy: make obtuse comments on code reviews that cause the developer to research half the day to see what it means because they feel stupid for needing to ask.
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
Holy shit, theprimeagen reacted to me! 🤯 Love it
Thank you for 16:42 you damn comedic genius
You've made it! Keep that neet code (and those neet takes) coming. 🏆🥳
He just got you a new sub
Man, the Java joke was fantastic!
Whew, that one went your way... this time. :)
2:48 - factory pattern
4:38 - builder pattern
6:36 - -singleton- arch user pattern
10:03 - observer pattern
11:40 - iterator pattern
14:21 - strategy pattern
16:09 - adapter pattern
17:56 - facade pattern
more like arch-user-ton patter :)
Arch user pattern aka game developer pattern.
"strategy pattern" aka function pointer
@@peaked2258 UGH... no.
Façade
Interestingly there are also functional programming patterns. I've got the full list here:
1. Functions
I have been studying design pattern for some exams and this is just GOLD!
Thank you for the laugh!😂
That is all you need
Lol, I'm studying design patterns after studying some functional programming and this is what I just realised. Strategy pattern == first class functions, visitor pattern == pattern matching!
True, Strategy pattern = higher order function, Iterator pattern = functor
Completely ignoring how functions can get other functions as an input, or even self-invoke them.
Reasons I find these react type videos to be among the top best things to be happening to my career:
1) I find out amazingly informative tech TH-camrs from the original videos
2) Primes constant interjections is basically 100x-ing the information
3) He’s so f*in funny.
4) This kind of gold only seems to flow from highly technical senior engineers in the creamy layer of companies
Thanks prime, continue to make these !
Couldn't agree more !
No offense to prime, and he's about as good an engineer as it gets. People that write business apps adopt the OO things because its useful in that context. engineering for large scale isn't the right context. I know people making $300k a year building salesforce apps, and $300k a year building large scale streaming systems. Context.
Constructive criticism: "Creamy Layer of companies" makes me uncomfortable 🥴
Reason # 5) You have brain damage.
Agreed
I love how some of the patterns are "wtf is that monstrosity" while others are "oh, that's a pattern? I thought that's basic doing things".
That's how the whole "patterns" thing started... a bunch of 4 guys were just trying to codify good ideas they'd seen so they could share them around. Things then... well. Things got a little out of hand.
MyClassFactory myClassFactory = new MyClassFactory();
MyClass myClass = myClassFactory.create();
BWA HA HAH AHA HAHAH AHAH AHAAA
I remember being asked which patter is a smart pointer in c++. I listed 3, before they told me it was a proxy and i was like yeah, i guess, but who cares?
Exactly, for example Singleton is simply a fancy name for a global variable!
So many religions in software nowadays
It's kinda weird ngl
Even IRL religions don't make sense, let alone software religions
Yeah, only religion that's valid it HolyC and TempleOS
Alahuakbar
@@BboyKeny long live the schizo god!!!!
(he works at Netflix btw)
I wonder where he works
Just realized 1994 is 30 years ago
tf?
i thought 30 years ago its 1970
8:08 Well, as an avid Python programmer, I can vouch that while using decorators feels pretty nice (most of the time), writing them is an absolute mind numbing experience.
same goes for rust macros: I love when they are provided but now I am writing them my sanity is simply not here any more
@@ShadowKestrel I'm doing the proc_macro workshop and doing the derive(Builder) macro as my first 1 since yesterday.
It's all fun and games, till I got to the optional-field part. I shudder at the realization that there are so many way to make a struct field optional and I would need to check all of them.
I'm just starting out with it so there are without a doubt tons of pattern and tools to help with these kind of things that I don't know of.
Although do think it's probably a very useful tool to have in my arsenal and way more powerful than macro_rules.
Me: "How does decorator work behind the scenes?"
Senior dev: "It just works"
@@ThatOpinionIsWrong with a smile on its face, that's how!
how a decorator works:
you write a function that takes in a function and gives back the "same" function
plus you can do code on the side
def print_instead(func):
return print
will give you a decorate that replaces the decorated function with print :D
I too love the strategy pattern. Higher order functions are the most beautiful way to do the strategy pattern. Functional programming is just the strategy pattern all the way down. I love the strategy pattern btw.
Do you love the strategy pattern?
@@iambilbobaggins1884 I think he loves the strategy pattern... Can he confirm?
@@Gamester-vy1qp I, too, wish I knew how he felt about this, and where/if he works.
i was a bit confused at the begining of your message - does he rly love the strategy pattern, but at the end I put aside my doubts - you DO LOVE STRATEGY PATTERN!
Bro. I think you love the strategy pattern
It would be cool to go through examples of patterns in rust. I haven't looked at the code for serde but it seems to use interesting patterns such as adapters to support different serialization formats.
are we going to just ignore the fact that he's using camelCase on Python?
@Chase Miller snake_case >>>>> everything else
@@tablettablete186 camel case is the only way
@@judewaide8328 oBjEcTivALy WRONG!!! 😤
(I wanna where this goes 😅😅😅)
@@tablettablete186 lol
@@tablettablete186 snake_case gang
I'm gonna take a shot every time you mention you work at Netflix
should i call an ambulance?
The pattern of choice at my job: The Spaghetti Pattern
> Buys patterns book
> Looks inside
> Interfaces
> 😐
Singletons are really nice for hardware abstractions in embedded systems. For example I only want one instance of my keyboard structure, not 2 or 20.
I actually want 20, one for japanese , English and macro all in 1 keyboard
Builder is my favourite. You can omit and add whatever you want, the depth and detail that you ask of the struct is (USUALLY) directly paired with the amount of chaining you do. You can go with defaults, specify a few parameters, add more if you need to, or you can do the equivalent of in-place initialisation (which although it may not be as performant unorganized unoptimised, compilers might recognise the simplicity of the chained functions and would be able to evaluate the code into an object literal).
TH-cam REALLY wanted me to watch this, popping up on my end screens and recommended list for like 2 weeks now. I finally watched it..... sadly I'm not far enough on my coding journey to have learned anything or understood what was going on other than the great Prime jokes🤣
I use the builder pattern for all my JS Web Components. I am surprised people are surprised at returning this. It works nicely with a functional style, too, with a builder class whose final commit returns a DOM node and other methods return this. The web component then basically builds as one function call that when returned returns the ready component.
You may get away with using not a single if else for a full and fully parametrised component with ES6 if returning this from each build method except commit. Listeners and any other features are just properties inserted with the builder as each sub component is described by joining build calls with the dot notation. The build tree will thus extrapolate to any complexity, as a component can always comprise any of the builds, which can comprise any builds, and so on, till the call stack returns to the top level and a full HTML component with any child components is returned, and is inserted in the DOM with the final commit. In theory, the whole web page could be built thusly.
Prettier than some React stuff I have seen.
the idea of patterns is great.
how people found patterns and tried to put everything in a pattern shaped hole was not.
specially when "patterns" became some sort of bizarre synonym of OOP
When someone confused patterns with OOP and confused OOP with classes it is quite difficult to take them seriously
@@avwie132i don't program, they come off pretentious at the least 😢
Why do you think that happened?
My suspicion is that most Modeling languages focus on OOP.
Video: Screw too small for the hole.
Primeagen: We've all felt this...
Me: I thought the idea was you couldn't feel it.
You know what you should feel by knowing what you don’t feel.
Some of the patterns are so ubiquitous that you almost don't need to know them. Like I don't need to know that air is called air because I just breathe it naturally
Python decorators are the best. They are the easiest form I saw for metaprogramming. It is really easy to read and understand the logic behind them
I'm just about to suggest in my project to start using a Factory for a single reason. We have 5 different classes that create the same object using a builder BUT it isn't clear how many fields of that class have to be set up(spoiler all of its parameters so always the complete builder). To isolate in a single place how the creation of that object has to be, enforce validations and ensure one of the fields that is a map is always created correctly depending on 1 of those 5 usecases. If not we will snowball into having distribuited the creation logic across multiple places
And *that* is what factories are made for. To unify and hide away complexity from the developer who shouldn't have to worry about that stuff, and you still need to have some unified way to create everything.
Oh, and I dislike factories (honestly not too keen of builders either) so I have every reason to absolutely shit on them. It's just that in some cases they actually do make sense. They are simply abused to infinity and beyond.
@@CottidaeSEA i feel like this how it goes for a lot of patterns. We hate them because of how they get misused, but by god they are very useful in their actual niche.
don't use a builder or factory if instantiation params are wonky/unknown. you should consider writing a context object. then any methods/classes that have the wonky/painful params pull from a single source. you'll see this a lot in JS when working with large libraries. There will usually be a single settings object which describes how the library should behave.
The key to keeping settings objects maintainable is making them immutable. Once you allow mutations to settings, you are no longer passing around context, you are passing around state. immutable context is predictable state is not.
@@NihongoWakannai Yeah, I feel like that also translates to OOP getting a lot of undeserved hate.
@@wadecodez Doesn't that pattern also use a factory? I've never seen it without a factory at least.
I usually think about the Facade pattern in terms of delineation between groups of developers, or major functions in an app... But one could just consider it a part of UX (or DX) → You make stuff easier to communicate, understand, and use.
I wouldn't think of it normally as an endpoint though - unless you were explaining the endpoint with docs in a "This is all you need to know to do this" sense.
But I think that perspective comes from seeing Facades as typically being a class with clear features, and not just any point that simplifies interactions between one system and other systems.
I don't know why but I crave more of these 💓💓
Common confusion: Observer is not Pub-Sub. Observers listen directly to their Observables/Subjects, so then each Observable/Subject must keep references to all of its Observers and become bound to their lifetimes. Publish-Subscribe adds one more level of indirection by having publishers and subscribers both depend directly upon a Channel between them; therefore they are tied to the lifetime of the channel rather than each other. Subscribers only become aware of publishers when notified with a message that provides the reference to the publisher if necessary.
Observer, Iterator and Strategy are great. Singleton is ok if you're careful with state (Rx singleton Observable for instance). Adaptor and Facade are unavoidable, but I hate how coupled they can get. Factory and Builder are meh - I feel they're needed sometimes but they get overused. ps. lol at Primer reacting to Python OOP in real time
14:00 I don't think you're supposed to raise exceptions on regular functionality (reaching the end of the list)
Saw the original before, generally good comments as far as my experience with these patterns go.
One critique I have is your statement that "Everything is a facade, becaus you hide information" with something something private. Facade does obfuscate variables and functions from the programmer, but they are still accessible from the outside. Basically, Facade (at least as stated in the GangOf4) is an interface to a functionality that says "Hey, 99% of the time, you will want to use me by calling these couple of functions here. If you need more custom behaviour and you REALLY know what you are doing, you can also tweak all my other variables and use these other functions". So Facade gives you a set of convenient functions to use it with, but also allows for access to everything else about the interfaved functionality, if you want to.
The only reason to use a factory is to hide the complexity of object creation. If a design pattern does not result in simpler code, then you are using the wrong design pattern.
Builder and factory are just semantic variations on a constructor. Builder just turns parameter assignments into individual functions that can be chained together.
I think the Singleton pattern as just a special case of "execution contexts" where there is only one global context.
It can simplify code by removing the need to explicitly pass down dependencies into the callstack.
However, as with all static globals, it creates global coupling.
staying with the python example from the video I would always rather use a construct as below instead of a singleton:
```python
with some_context_of_type_y():
with some_context_of_type_x():
foo()
def foo():
y = get_y_object()
x = get_x_object()
```
IMHO it gives better composability on the outside scope and has the same advantages as singletons on the inside scope.
Yea there are very few scenarios to actually use this pattern once you have DI, in fact it only interferes with/breaks DI. The only two examples I can think where I would actually use it are A) a tiny app where I'm not going to include an IoC library or B) In the very initial boot of your app when the IoC container/AppContext is either half constructed or has not finished initializing and is in an unsafe/incomplete state, yet you still need access to critical components like a preInit logger.
Cause if AppContext fails to initialize... and that's where you get your logger from... and you want to log the error... and it IoC fails to initialize.... so you want to log it... but it has the..... wait.. where was I? where am i? WHO ARE YOU PEOPLE???? Can someone call my mom, im scared
Reactive programming works a lot with Observer, Iterator and Strategy patterns. For some historical insight, it's called RX because Microsoft did a lot of work with something called Reactive eXtensions, hence it evolved to RXJava.
I love how straight to the point reactions Prime Reacts have
Peak of OO culture: Implementing Strategy and Visitor patterns (I still can't implement the visitor pattern without looking it up).
Peak of FP culture: Monad transformers
I still don't know wtf is a monad.
@@wlockuz4467 SIMPLIFIED: it's a "wrapper", which takes closures/functions/lambdas which modifies the internal data (aka map function)
It also needs a "pure/unit/wrap" function and also a bind/flatmap function.
*Example without monads:*
let person = Person { name: "John" };
function print_name(person: Person) {
if person != null {
if person.name != null {
print(person.name)
}
}
}
print_name(person);
*Example with a monad (Option):*
let person = Person { name: "John" };
function print_name(person: Option) {
person.map(p -> p.name).map(name -> print(name));
}
print_name(person);
@@wlockuz4467 Instead of getting the data and applying your code to it (like a loop), you pass your code to the monad an IT will apply your code to the data. You just don't exactly know if, how or when cuz abstraction, which is the entire point. For example, in an Option/Maybe/Try monad your code will only be applied to the data if it exists.
outside of Monad Transformers you have MTL, Lenses and for many types of programs instead of using MTL many people use Freer Monads/Extensible Effects. Also arrows
the arch user strategy pattern sounds interesting
“Patterns” is just something to grab if you don’t have lambda, the ultimate abstraction
Decorators are one of my favorite things about Python. They're so fantastic.
One of the most useless language feature :) They have very limited use if you do not want to end up with totally unreadable code.
I used to dislike decorators, but I'm currently working in C# (which doesn't have them) and I keep running into instances where it would be really nice...
I have a class that makes API calls asynchronously, but I need to limit the number of async calls being made at a time. So, I need to use a semaphore to force threads to await if all the other threads have used up the semaphore. Would be super nice to just use a decorator at the top of every method that makes an API call so that it wraps the execution with an await to the semaphore, but not an option for vanilla C#. I ended up creating another class called RequestExecutor that has methods that take lambda functions and do this instead, but it feels less clean.
@@banatibor83 If you think decorators are bad, what about the abstractfactory patterns here. They are used for black-box aspect oriented programming to simplify your code, and are in JavaScript as well.
Great comment at 15:48 . From a functional perspective, the "interface" you are crying out for, is just a function.
However I don't think it's worth a full fedora-tip here, because as competent engineers we need to be prepared for any situation we may walk into. Such as George Clooney walked into in From Dusk Till Dawn.
16:30 I recently had a similar problem.
My solution was buying bigger screws.
Ngl... sometimes listening to the definitions of these named patterns,I feel like the next one is gonna be "and the Typing Pattern is where you press keys on the keyboard to put code in a computer!" "The Press Play Pattern is where you have to click a button to make your code run after it's written!"
Facade = Noise Adapter
Adapter = Interface Strategy
Strategy Pattern = interface.method(strategy) = noun.verb(how)
Adapter = noun2.verb(noun1.verb(how))
Facade = () => noun2.verb(noun1.verb(how))
8:25 - What is this contraption??
16:18 - ngl this caught me off guard mid drink
I am convinced that the US has a different Java than the rest of us.
The only place I know of that has abstract factories are frameworks like Spring.
Because Spring can make a case for "I need to have a way of producing objects of whatever type specified", as well as "and I need to allow more than one way of doing it".
And that's just because of the very generic way the IoC-container works.
You could have a class called Food.
It can be composed of an array of various ingredients and include a name variable.
2:48, they just gave a name for a thing that has been made in C for decades:
struct CheeseBurger { const char *ing_1, *ing_2, *ing_3 };
#define createCheeseBurger CheeseBurger { "bun", "cheese", "beef-patty" }
And then call it by:
CheeseBurger a_cheese_burger = createCheeseBurger;
5:20, this is a "lesser version" of C++ for 2 reasons:
a) If 1 just wants to customize the initialization, C/C++ way is much better, as exposed above, due to compact syntax.
b) If the goal is to customize it along the way, not only on initialization, it should has a control of which f() is allowed do that - _and it seems that only C++ has this feature_ . Otherwise, all sorts of bugs can come from it, because everything will be public, which is the worst nightmare, depending on the project complexity.
10:57, why use an interface for that? Couldn't it be just a class? 16:00, again, why an interface? This thing is awkwardly slow!
21:00, and that's why f() programming < OO: the 1st lacks good facades. In C, you can let that memory management "encapsulated" away in a different file. But there are issues:
a) Each file like this will be dedicated to each object, which hurts scalability.
b) If only 1 generic file like this is created, then the user will has to keep traveling alongside with that array, which is exposed to dumb mistakes for long unnecessary time.
It's still possible to create several macros, trying to hide that array exposure, but it's still a precary solution.
This video was good. Why? We learnt something, unlike some videos where you just rant or do irrelevant optimisations, in this I actually learnt something which can get someone hired.
Rant material is often a flash-forward to a problem or conflict that you just haven't run into YET -- artifacts of some clear, prior trauma.
i really didnt know that prime worked at netflix, im glad he mentioned it 10 times
As a netflix btw guy Prime could/should have really said a bit more about the observer pattern. ReactiveX was a live changer for me, and that netflix talk about it sold it to me, back then.
Close your eyes and listen and you half expect Prime to throw out a random "Morty" during his speeches. Y'ALL KNOW I'M RIGHT (seriously though if Prime wasn't a software dev he could probably take over for Rick's VA)
Thanks for going over this. I feel like I must be missing something because I’ve watched this and Fireship’s video on it and feel like this doesn’t actually help me think about the way data can be structured or organized.
I’m a high school teacher, so working on learning to relay the lessons to students in my CS classes. Thanks Prime. 😊
The main idea is to not reinvent the wheel every time a similar problem occurs. Back when the book came out, the idea was that software engineering was a relatively new discipline in comparison to e.g. engineering or architecture. So they started to look for standard solutions in patterns at the design or implementation stage of a project
@@spittylama Thank you. I do understand that’s the *purpose*; I’m saying I can tell I still have yet to understand the content.
I have been working on building projects with data, but I’m not sure I see the patterns, yet. I hope that makes sense.
@@mchisolm0 patterns with data are even more recent! So no worries with that. The well established patterns often have a OO design approach.
@@spittylama do are you saying this is *not* about patterns with data? If so, I must have been really misunderstanding…
That casual "when I was at Google" also got me going "weird place to flex, bud" 😂
First video from this guy that I like
It's funny how the borrow from the French language lost the cédille, but kept the pronounciation : it's façade in French, where ç is pronounced like double s
Dr.disrespect of programming
love the design patterns book, great video!
This is exploding my brain - ive had such a hard time listening to other peoples coding videos. Not this, im fully engaged. Thank you!
The implementation of the linkedlist iterator in the video is actually faulty. If you would create two iterators they would actually both modify the object.
I loved head first design patterns 🥰
The book is just so awesome. The way they teach design pattern by first introducing the problem and slowly building up the solution is great!
The idea of a factory is to provide only one interface create so client class could use it to create object of given interface. Like when you need some default value (like in data classes) when constructing object.
You mean like a function 😅
The factory pattern for this isn't needed you can just do this: Burger.Vegan = lambda **kwargs: Burger(ingredients=['special sauce', 'salami'], cook=lambda: Grill(temp=50, **kwargs), **kwargs)
this channel is my favorite netflix advertisement
Python canonically uses exceptions for control flow lmao. Exception zealots in shambles
Iterators in java: sugar
Iterators in Rust: honey
Iterators in python: 8 year old stevia packet
12:50 i had the similar experience. Microsoft tried to hire me with a 40% cut of my city salary. They said oh but we do value you, we intend to hire you out to clients for $5000 a day. This was in 2000 when $5000 was still quite an impressive amount.
This guy is intense. But i think he works at Netflix right?
Builder isn't "better" than factory, they are just suited to different circumstances - builder for flexibility; factory for simplicity. E.g. a library class uses builders in order to provide maximal functionality, but an app using that library wraps this in a factory to provide a simpler interface for the small number of specific uses its needed for in that app.
I just tend to find that factories are not what I want, yet. That's what I find myself doing. But a builder almost universally is what I want. Oftentimes you can even interchange them and I find the results almost always better with builder and a good setup defaults
I agree with Prime. I’ve never liked factories. They aren’t as flexible as builders.
I first thought it was about PrimeReact UI Library.
Your videos are fun to watch; I've subscribed.
Design patterns in functional programming:
strategy pattern: functions
builder pattern: functions
observer pattern: functions
adapter pattern: believe it or not also functions
Builder pattern is record syntax + functions, adapter is record of functions.
Functional programming uses functions instead of objects, this checks out.
9:50 "shared mutable state is the bane to all programming and the key to super awesome amazing performance and it is the scariest thing in the universe...so...careful."
As a Java developer I stay away from factories if I can. But yes, I've had my share of Complicators on teams.
And yes, (fluent) builders to create immutable instances ❤
I hate the new keyword that forces you differentiate between factory methods and class constructors, well at least the IDE can fix it for you.
11:00 Yeah, yeah, but there are languages *cough* where managing the lifetimes of the subscribers kept in the list can cause you a lot of trouble, and even using smart pointers might not save your day in cases where certain strange runtime dependencies in the destructors cause race condition or some runaway loops or similar fun. And yes, Facade is not an actual pattern of it's known, it's only a special case of the Wrapper.
I love the builder pattern, it's so useful. And the factory pattern is also super helpful
In Python keyword arguments and dictionaries tetrisgame(func1={arg1: 5}, object2={arg2: object3}) can replace builder pattern...
@@aoeu256can you elaborate?
It is only useful when you need to control what actually gets instantiated or how it gets configured during or after constructing.
In all other cases, just doing a "new" of the proper class is both simpler and easier to follow.
So if there is this need, sure, go for it.
But I will never consider it a pattern to default to.
Primogen really souds like a young Rick, from Rick and Morty. I dont have time for making this but just close your eyes and imagine it. Add some burps and voila. I think its the rhythm.
That opening was like a man confessing adultery to his wife.
"I work at Netflix btw"
has similar vibe as
"I use Arch btw"
builder pattern with rust is good because of the TypeState Pattern
On the last point of the facade pattern, NeetCode says "you don't want to think about memory allocation" and here I'm thinking "it isn't difficult at all, there is this thing called realloc." The only reason why it sucks in java is because java does precisely this, remove any need for you to think about memory allocation. Realloc is a better abstraction than java.
"btw, I work at Netflix"...
"Oh, you work at Netflix? Why don't you ?"
lol
Did I hear I hate decorators? How do you love this though? #[Derive(Debug,Clone,Display)] on all your structs? :)
I had that book. I tore it apart before I trashed it so nobody else would be infected by it.
19:00 I expected facade being something like "struct NodeId(usize);"
Internally it's just an integer, but you can't use it like an integer.
Haha! Creational patterns look to me like a solution to several problems all bundled together as OOPsies!
"if only...if only react was dying"...lol you get a million internet points
Laughed at the, "is this bash now!?" comment 😂
beginner question:
what's the difference if I just use: new Burger("bun-type", "patty-type", "cheese-type"); vs the builder pattern?
The main difference is if there's a varying amount of options when building an object.
Say that I'm a really weird person and only want a burger with only a bun (no patty or cheese). Then I can use burger = BurgerBuilder().addBun().build()
Or if I only want bun with cheese (no meat), burger = BurgerBuilder().addBun().addCheese().build()
Otherwise you'd need several different constructors to handle every possible combination (which quickly gets messy when multiple options are involved.)
The burger example is not the greatest to show this difference but hopefully that made some sense
the code is in Python but you used the new keyword hahah. You don't need builder in Python cuz of default arguments, keyword arguments and dicts in Pythons.
@@zachmanifold ooh,, now that you said something about those constructors, I got it now, thanks! :)
8:00 No, if used like this, singeltons are pretty stupid. I just use them when I can't have global state, or I don't have control over the main function or something similar. (only in Unity)
And I never define a static method when using them. I just use a public static parameter, or different static methods to access it.
The only thing wrong with the phrase "JavaScript was a mistake" is the implication that JavaScript is only one mistake.
I did use a factory on my own.
Needed to make a bot object that needed to load a few things from files assorted with a user Id.
It was actually a ton of fun
Where did you work again? Was it Prime Video?
(ducks)
I usually prefer default in Rust over the builder pattern. I do emit part of this is because it's a lot easier to implement. I don't normally mind using the builder pattern but I hate programming it. Also I feel like it doesn't normally have much of a benefit so I don't know if it's worth implementing in most cases.
Bro I watch your videos everyday huge respect . I learn lot here .
:) ty ty
Singletons are fine if they contain no mutable state.
At my work we use singleton lifetime DI extensively because all state is passed through arguments and returns. Classes become modules and interfaces make those modules loosely coupled.
It's almost like functional programming but with a nicer syntax.
Why not just use a static class then? Genuinely curious the difference between a singleton and a static class, I'm sure they are drastically different I just don't know how.
@@grantpeterson2524 In javascript and python there is a memoize (called lru_cache) method that caches calls for functions, the memoization of a no argument function is called the singleton. Static classes run code at the start of your program, while singletons are initialized the first time they are used.
Facade is not even a pattern, it is a higher level architectural decision.
I use strategy, iterators, PubSub and builders all the time. They are second nature. I also use decorators a lot. IMHO they are almost magical, especially when coupled to strategy patterns.
Patterns that blew my mind are Command, Visitor and bridge pattern.
When do you ever not care about how the thing is put together?
Seems to me that's always relevant or essential to the specific situation.
I almost spit out my granola at this comment: "code review feedback: 'more façade'"
sounds like a good "-10x" strategy: make obtuse comments on code reviews that cause the developer to research half the day to see what it means because they feel stupid for needing to ask.
Decorators are GREAT!!!
17:45 Adapter pattern is just the application of a strategy pattern.
"Can we pause for a second? I hate decorators"
Hahahahaha