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?
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 UA-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.
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!
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!
UA-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🤣
Builder and factory are just semantic variations on a constructor. Builder just turns parameter assignments into individual functions that can be chained together.
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.
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 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
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).
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'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.
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.
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 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.
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.
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.
There are a few differences. For one derive macros can only be used on types (struct, enum, union), they see the definition and return the implementation for a certain trait and can't really do much else. Rust also has attribute macros which are less often used but they are a bit more similar to decorators. However Rust macros will always run at compile time and work on the syntax tree, where Python decorators run at runtime and work on class or function instances. Since the decorators in Python are running at runtime, they can already call functions and access attributes in the classes which isn't really possible with macros in Rust.
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.
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.
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.
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.
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
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.
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 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.
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.
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.
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
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.
The strategy seems useful but when would be a good time to use it compared to just having a regular function in the example it uses it strip out odd or negative numbers which you can just do with a function and it will be more easily understood i guess?
The exact example they gave could have used a lambda as an argument. But in cases where more complex operations need to take place, but the inputs must be the same across invocations, then a strategy pattern is useful.
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.
2:45 I'm completely missing why the factory is a separate class and not just a set of static create functions on the burger. Am I just to imagine we're passing the factory somewhere to use as a customization point? So others can make the burger I want. This just feels like code obfuscation until you have a LOT of places where you instantiate burgers that all should be uniform or at least follow the standard as a baseline. Alternatively a very complex standard burger. But if that's all I still think the static method makes more sense. It also seems like a mess to have such diverse objects that don't express that in the type system. Code that operates on burgers with customization significant enough that you have to abstract away some complex init function must be very hard to operate on and it doesn't seem the code subdivides the problem enough. The example doesn't show that because it's too simple to even consider writing. 5:00 Even more confused now. The builder pattern doesn't seem to be replacing the factory.
It doesn't need to be a class in python, you can just make a factory function. Also the example is not ideal. The factory pattern usually instantiates different subclasses, with different internal implementations. Using the pattern for different sets of arguments is not the common usage that describes the pattern.
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 ❤
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.
When I try Observer i end up with events of things that happened in reaction to some other event and stuff happening in random order and it turns out order matters and everything goes to sh*t what am I missing?
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.
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.
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)
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
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
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!
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 UA-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
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.
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
> Buys patterns book
> Looks inside
> Interfaces
> 😐
The pattern of choice at my job: The Spaghetti Pattern
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'm gonna take a shot every time you mention you work at Netflix
should i call an ambulance?
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?
@@Gamester1128 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
UA-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🤣
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.
Builder and factory are just semantic variations on a constructor. Builder just turns parameter assignments into individual functions that can be chained together.
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.
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
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
“Patterns” is just something to grab if you don’t have lambda, the ultimate abstraction
i really didnt know that prime worked at netflix, im glad he mentioned it 10 times
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.
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
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.
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).
That casual "when I was at Google" also got me going "weird place to flex, bud" 😂
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
Did prime stutter so much as a meme that he now just has a stutter
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
I love how straight to the point reactions Prime Reacts have
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.
All the patterns that seem simple and commonly used now show that these designs really were foundational.
the arch user strategy pattern sounds interesting
I don't know why but I crave more of these 💓💓
14:00 I don't think you're supposed to raise exceptions on regular functionality (reaching the end of the list)
Iterators in java: sugar
Iterators in Rust: honey
Iterators in python: 8 year old stevia packet
idk why but it feels so cursed to see many classes defined on the same file
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!
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!
That opening was like a man confessing adultery to his wife.
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…
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!"
this channel is my favorite netflix advertisement
I first thought it was about PrimeReact UI Library.
Your videos are fun to watch; I've subscribed.
First video from this guy that I like
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.
"Can we pause for a second? I hate decorators"
Hahahahaha
"btw, I work at Netflix"...
"Oh, you work at Netflix? Why don't you ?"
lol
Laughed at the, "is this bash now!?" comment 😂
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.
he looks so guilty when talking about factories :P
"I work at Netflix btw"
has similar vibe as
"I use Arch btw"
You could have a class called Food.
It can be composed of an array of various ingredients and include a name variable.
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.
How are decorators different from derive macros in rust?
One is RUST and the other is NOT RUST
There are a few differences.
For one derive macros can only be used on types (struct, enum, union), they see the definition and return the implementation for a certain trait and can't really do much else.
Rust also has attribute macros which are less often used but they are a bit more similar to decorators. However Rust macros will always run at compile time and work on the syntax tree, where Python decorators run at runtime and work on class or function instances.
Since the decorators in Python are running at runtime, they can already call functions and access attributes in the classes which isn't really possible with macros in Rust.
I'm a rust fanboy, but true.. they're pretty much the same tbh
16:30 I recently had a similar problem.
My solution was buying bigger screws.
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.
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 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.
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.
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
"if only...if only react was dying"...lol you get a million internet points
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.
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 😅
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! :)
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.
Haha! Creational patterns look to me like a solution to several problems all bundled together as OOPsies!
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.
I had that book. I tore it apart before I trashed it so nobody else would be infected by it.
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
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.
Can you not say "okay google" while I'm driving? It pauses the video! :p
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))
Things i've learned in this Video -> Prime works at Netflix 😂
Bro I watch your videos everyday huge respect . I learn lot here .
:) ty ty
What is the iterator pattern?
14:11
It's just a loop!
The strategy seems useful but when would be a good time to use it compared to just having a regular function in the example it uses it strip out odd or negative numbers which you can just do with a function and it will be more easily understood i guess?
The exact example they gave could have used a lambda as an argument.
But in cases where more complex operations need to take place, but the inputs must be the same across invocations, then a strategy pattern is useful.
Python canonically uses exceptions for control flow lmao. Exception zealots in shambles
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.
4:20; Composition over Inheritance
2:45
I'm completely missing why the factory is a separate class and not just a set of static create functions on the burger. Am I just to imagine we're passing the factory somewhere to use as a customization point? So others can make the burger I want.
This just feels like code obfuscation until you have a LOT of places where you instantiate burgers that all should be uniform or at least follow the standard as a baseline. Alternatively a very complex standard burger. But if that's all I still think the static method makes more sense.
It also seems like a mess to have such diverse objects that don't express that in the type system. Code that operates on burgers with customization significant enough that you have to abstract away some complex init function must be very hard to operate on and it doesn't seem the code subdivides the problem enough. The example doesn't show that because it's too simple to even consider writing.
5:00
Even more confused now. The builder pattern doesn't seem to be replacing the factory.
It doesn't need to be a class in python, you can just make a factory function. Also the example is not ideal. The factory pattern usually instantiates different subclasses, with different internal implementations. Using the pattern for different sets of arguments is not the common usage that describes the pattern.
8:25 - What is this contraption??
16:18 - ngl this caught me off guard mid drink
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.
builder pattern with rust is good because of the TypeState Pattern
Is the strategy pattern just more complicated higher order functions?
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.
By the way, if you guys didn't know that... he works at Netflix
When I try Observer i end up with events of things that happened in reaction to some other event and stuff happening in random order and it turns out order matters and everything goes to sh*t what am I missing?
Decorators are GREAT!!!
This guy is intense. But i think he works at Netflix right?
17:45 Adapter pattern is just the application of a strategy pattern.
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.
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.
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)
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
I agree with Prime. I’ve never liked factories. They aren’t as flexible as builders.
Lost my shit at the bleeps for "factory" HAHAHHHAHHA
I have a feeling that this guy works at netflix