I've been watching some of your Design Patterns videos for a uni exam. Great explanations with really good visual examples. They are very helpful thank you!!
I think you missed the part where the command pattern can be used to undo or redo an operation. Great clips though, I use them as quick summerization guide in addition to the design pattern book (gang of 4).
First of all, thank you for the explanation, it was all well presented. However, I still have few questions: 1. I don't see how the code prior the pattern is that much coupled. Could please point out some dependencies or changes that could be made on the Light class that would lead to crash in the subclasses? 2. It's not clear for me where I can use this pattern. Any system where I have a command? Perhaps it was too much to ask, but if anyone can help me out with this, I'd be much appreciated.
Hello! Glad you liked it! 1- In the first implementation, everytime you add stuff to your Room (like Lights) all subclasses are affected, and as the list of attributes added grow, these Rooms will be handling many responsibilities. In addition to this they are aware of these functionalities. When we used the command, this became generic, the Rooms are not aware anymore of what is being executed, just that it can execute something, and all the code related to Lights for example is now encapsulated in its own class (this is explained from 2:50 to 4:00 if you want to check it out again) 2- The command pattern decouples the classes that invoke the operation from the object that knows how to execute the operation. One use-case for using this pattern is that the executor of the command doesn't need to know anything about what the command is executing, what attributes it needs or what it actually does, as that is encapsulated in the command. This allows you to have a list of commands that are executed in order for example, that are dependent on other items without being dependent on the executor, that are triggered based on a certain event... Hope this helps! Cheers!
Thank you for the video but in 4:35 uml diagram you draw the arrow to invoker from client. But in the other resources there is no connections between them. Is it mistake or what?
"private Light light" in SwitchLightsCommand is a pointer to Light object not an actual Light object. It doesn't point to any Light object until "new SwitchLightsCommand(new Light())" in the main function. "new" indicates that your dynamically creating the actual object and then that is being passed into the SwitchLightsCommand constructor.
Thank you. Love your videos so much. Have a question. How can we know that the LivingRoom's lights are on? I suppose we should have created something like livingRoomLights variable instead of just passing `new Light()` so we could have known that from the client code. Or wrap all of that with another class around the livingRoom and the livingRoomLights objets.
I'm sorry to say that the command pattern, like many other OO patterns, is just one prime example of how OO fcks itself by not treating functions as assignable values. What is a command? It's one hell of a weird way to define a function abstraction. Here is this thing that will call a function if you poke it. Oh yea the function can change, and the thing you are poaking abstracts away what the concrete function is. "But commands are objects that can have state and yayayayayyayadaydadada". Yes, but when you just look at the invoke function in is a function that does something before, maybe during, and after a dynamic function call. You might as well just have a wrapper function composed with a predefined state context. Is this hard? No. Is it just a fancy way of making a function return a function, and calling that function? Yes. Bohooo a returns b composed with parameter c from a. Call b, and it does the spookies. I do see how the command pattern has its usages, but it's an ugly way of saying that you can't pass functions as values, and that you can't produce them either. It's a fckd wrapper. But nice vid tho very informative, keep it up ♥
Yeah, many design patterns can be replaced with HOFs, closures, composition, HKTs etc... But even so, and even in languages with both OOP and FP capabilities (TS, Go, etc...), you can learn a lot by understanding these patterns, why they exist and how do they solve common problems and allow for mor maintainable code.
I am just wondering, with the command pattern setup, Now Livingroom and Its Light object are not related anymore. How do we tend to preserve the relationship here. To my doubt, I believe we don't have relationships here is because its a kind of a Behavioral pattern and not Creational pattern. Please correct my understanding, I am here to learn.
Your understanding is on the right track. In the context of the Command Pattern, relationships between objects are not necessarily established through direct associations in the traditional sense. Instead, it promotes a more flexible and loosely coupled structure, where the sender does not need to know the specific class of the receiver. (Maybe the nature of the example here confused you a little). The Command Pattern doesn't explicitly deal with establishing relationships between objects in the way Creational Patterns might, it indirectly influences the interactions between objects by decoupling the sender and receiver.
you use classes on slides but in the repository there are stupid records which does not compile because of java version. was that so necessary switching from classes to records and upgrading version of jvm?
@@geekific would have been much better if your slides and your repo were 100% synchronized. Many classes you show on the slides are not even present in the repo. And again, using latest features of the language for rather simple tiny project is not the best choice.
I think the example is slightly unrealistic as one would unlikely make a class for each room in a house, since the developer has no idea what kind of rooms will be in the user's house. (What if the user has a "sun room" for example or if the "room" is actually an outside space such as a pool area.) I think this is unrealism is a distraction from the core message. It would make more sense for a room to have a name attribute and a list of "things". Alternatively, you could just use a different example. It's also weird that the room has no reference to the objects themselves. For example, there's no way to ask a room if a light is on or off. This information would be essential to making a user-interface phone app. For the curtain example, you might want extra functionality. Perhaps you want the curtains to be 50% open or 33% open. However, this functionality isn't compatible with a (non-dimming) light as on/off is boolean. You can further imagine a light that can change colors. We would now need to pass 2 numbers (hue and saturation) to specify a given color (assuming you want brightness to be independent of color) In general, it seems better to send a command somehow, but I can't see exactly how that would work.
I remember that coming up with an easy example that allows us to focus on the pattern more than the actual use-case was hard here. I hope we were able to relay this information regardless of the messed up use-case xD
I like your presentation but the pattern still makes little sense to me. Looking at the code on time 4:00, you still have the exact same thing as on time 0:55.
Thanks. The difference is that at 0:55 the rooms are aware of lights, however, at 4:00 they are decoupled, you can pass in any type of command you want. And of course they might seem similar, because the idea is not to change the functionality, this has to remain the same, all we want is aim for a cleaner code.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Great job. I can say I'm learning more with your videos than going to class. In 7 minutes you accomplished what my teacher tried in 45minutes😂
Same in my case😂
I've been watching some of your Design Patterns videos for a uni exam. Great explanations with really good visual examples. They are very helpful thank you!!
Awesome work! Such content is very necessary, don't stop doing what you do!
Thanks a lot, glad you like it, will do!
Your explanations are most relevant and spot on! Gives the gist of every pattern in very little time. Thanks for doing this.
really nice work :) this so much better than my degree explanations.
Thanks always for these insightful, scenario-based videos that help us grasp these Software Design Patterns.
Wonderfully explained, thanks! Going to explore all your other videos!! Keep going. Thank you
Awesome, thanks for the support!
You have earned a sub with down to Earth example 🙂
Thank you for the support :)
Geekific, thanks for what you are doing ! You videos are so cool.
Literally the best! Tysm
Glad it helped :)
Very Good explanation!
I think you missed the part where the command pattern can be used to undo or redo an operation. Great clips though, I use them as quick summerization guide in addition to the design pattern book (gang of 4).
I think the relationship between Invoker and Command is aggregation (as Invoker contains a field of type Command), not association.
First of all, thank you for the explanation, it was all well presented. However, I still have few questions:
1. I don't see how the code prior the pattern is that much coupled. Could please point out some dependencies or changes that could be made on the Light class that would lead to crash in the subclasses?
2. It's not clear for me where I can use this pattern. Any system where I have a command?
Perhaps it was too much to ask, but if anyone can help me out with this, I'd be much appreciated.
Hello! Glad you liked it!
1- In the first implementation, everytime you add stuff to your Room (like Lights) all subclasses are affected, and as the list of attributes added grow, these Rooms will be handling many responsibilities. In addition to this they are aware of these functionalities. When we used the command, this became generic, the Rooms are not aware anymore of what is being executed, just that it can execute something, and all the code related to Lights for example is now encapsulated in its own class (this is explained from 2:50 to 4:00 if you want to check it out again)
2- The command pattern decouples the classes that invoke the operation from the object that knows how to execute the operation. One use-case for using this pattern is that the executor of the command doesn't need to know anything about what the command is executing, what attributes it needs or what it actually does, as that is encapsulated in the command. This allows you to have a list of commands that are executed in order for example, that are dependent on other items without being dependent on the executor, that are triggered based on a certain event...
Hope this helps! Cheers!
best content.
So glad you are enjoying our videos :)
Thank you for the video but in 4:35 uml diagram you draw the arrow to invoker from client. But in the other resources there is no connections between them. Is it mistake or what?
Amazing content
3:56 it is strange, because we pass some light in SwitchLightsCommand, but this light, created in the previous line, is not a light of the room
"private Light light" in SwitchLightsCommand is a pointer to Light object not an actual Light object.
It doesn't point to any Light object until "new SwitchLightsCommand(new Light())" in the main function.
"new" indicates that your dynamically creating the actual object and then that is being passed into the SwitchLightsCommand constructor.
Thank you. Love your videos so much. Have a question.
How can we know that the LivingRoom's lights are on?
I suppose we should have created something like livingRoomLights variable instead of just passing `new Light()` so we could have known that from the client code.
Or wrap all of that with another class around the livingRoom and the livingRoomLights objets.
Glad you do! Thank you :)
This code is strictly to demonstrate the pattern you can expand on it as you wish.
I'm sorry to say that the command pattern, like many other OO patterns, is just one prime example of how OO fcks itself by not treating functions as assignable values. What is a command? It's one hell of a weird way to define a function abstraction. Here is this thing that will call a function if you poke it. Oh yea the function can change, and the thing you are poaking abstracts away what the concrete function is. "But commands are objects that can have state and yayayayayyayadaydadada". Yes, but when you just look at the invoke function in is a function that does something before, maybe during, and after a dynamic function call. You might as well just have a wrapper function composed with a predefined state context. Is this hard? No. Is it just a fancy way of making a function return a function, and calling that function? Yes. Bohooo a returns b composed with parameter c from a. Call b, and it does the spookies. I do see how the command pattern has its usages, but it's an ugly way of saying that you can't pass functions as values, and that you can't produce them either. It's a fckd wrapper. But nice vid tho very informative, keep it up ♥
Yeah I’m not reading all that, but I’m happy for you or sorry that happened.
Thanks for such insights to know what I am getting into.
Yeah, many design patterns can be replaced with HOFs, closures, composition, HKTs etc... But even so, and even in languages with both OOP and FP capabilities (TS, Go, etc...), you can learn a lot by understanding these patterns, why they exist and how do they solve common problems and allow for mor maintainable code.
everyone gangsta until sander death stares you
I am just wondering, with the command pattern setup, Now Livingroom and Its Light object are not related anymore. How do we tend to preserve the relationship here. To my doubt, I believe we don't have relationships here is because its a kind of a Behavioral pattern and not Creational pattern. Please correct my understanding, I am here to learn.
Your understanding is on the right track. In the context of the Command Pattern, relationships between objects are not necessarily established through direct associations in the traditional sense. Instead, it promotes a more flexible and loosely coupled structure, where the sender does not need to know the specific class of the receiver. (Maybe the nature of the example here confused you a little). The Command Pattern doesn't explicitly deal with establishing relationships between objects in the way Creational Patterns might, it indirectly influences the interactions between objects by decoupling the sender and receiver.
you use classes on slides but in the repository there are stupid records which does not compile because of java version. was that so necessary switching from classes to records and upgrading version of jvm?
Hello! If you are using IntelliJ, you can easily convert from records to classes using the drop down options of the Alt+Enter menu :)
@@geekific would have been much better if your slides and your repo were 100% synchronized. Many classes you show on the slides are not even present in the repo. And again, using latest features of the language for rather simple tiny project is not the best choice.
I think the example is slightly unrealistic as one would unlikely make a class for each room in a house, since the developer has no idea what kind of rooms will be in the user's house. (What if the user has a "sun room" for example or if the "room" is actually an outside space such as a pool area.) I think this is unrealism is a distraction from the core message. It would make more sense for a room to have a name attribute and a list of "things". Alternatively, you could just use a different example.
It's also weird that the room has no reference to the objects themselves. For example, there's no way to ask a room if a light is on or off. This information would be essential to making a user-interface phone app. For the curtain example, you might want extra functionality. Perhaps you want the curtains to be 50% open or 33% open. However, this functionality isn't compatible with a (non-dimming) light as on/off is boolean. You can further imagine a light that can change colors. We would now need to pass 2 numbers (hue and saturation) to specify a given color (assuming you want brightness to be independent of color)
In general, it seems better to send a command somehow, but I can't see exactly how that would work.
I remember that coming up with an easy example that allows us to focus on the pattern more than the actual use-case was hard here. I hope we were able to relay this information regardless of the messed up use-case xD
I like your presentation but the pattern still makes little sense to me. Looking at the code on time 4:00, you still have the exact same thing as on time 0:55.
Thanks. The difference is that at 0:55 the rooms are aware of lights, however, at 4:00 they are decoupled, you can pass in any type of command you want. And of course they might seem similar, because the idea is not to change the functionality, this has to remain the same, all we want is aim for a cleaner code.
OOP is a mental asylum
Srp be like😮😮😮
Little bit complicated
Please let us know which parts were the most confusing so we may try to help in the comments :) Cheers!