 This video was brought to you by my patrons, thank you so much for your support! Hello there, continuing the series where we are talking about design patterns, today we will see a very interesting pattern because the problem that it solves is very very common but we often just ignore the problem, but without further ado, let's get started. So we are talking about the new object pattern, a pattern that is not very well spread, not everyone knows about it, but it has some documentation we will see in one of the books that we are using here in this series that it has a very well-defined description and application of this pattern. So let's see its definition. So the new object pattern intends to encapsulate the absence of an object by providing a substitutable alternative that offers suitable defaults to a nothing behavior to something that doesn't do anything. And we can see the problem here that given that an object reference may be optionally no and that the result of a no check is to do nothing or use some default value, how can the absence of an object, the presence of a no reference, be treated transparently? So if you are not used to this problem, the checks of no and the usage of no values is very well known by experienced developers that the usage of no is something that we should avoid because if you have some checks for if you receive something that is no or if some value is no, it's probably because you have some problems in your design, the design of your code. To the point that on GDQuest guidelines, so I will put a link in the description for this, we explicitly say that you should avoid the no usage like a plague, like you should avoid it at all costs and instead you should try to use alternative for that. You should only use no if you are faucet too. We also have a reference for talk that the guy that created the no references gave that he says that this is a mistake, the no reference shouldn't even exist. So with that said, let's go back to the no object patterns and try to implement them in Godot engine. So here we are in Godot engine. For the implementation of this no object pattern, I will actually use the previous video project for the command pattern. If you didn't watch this video, please go to and watch it because you will need to understand what this project does to understand the power of the no pattern. So just pause the video here, watch the card that is appearing on your screen right now, watch the video and go back here. So let's continue. We have here some commands for the actor. So we have a walk command and we have some inherited scenes for this walk command. Each scene walks towards a direction. And here we have a command, an actor command that is the parent class of this walk command. So let's open the actor, actor here. And if you remember, we have a button for each of these commands. So we have a button that receives a command and when it is pressed, it adds this command to the command queue. Okay, so we have here in the actor, we have a add command to and each of these buttons will add this command to the command queue when they are pressed. Let's create a new command here. So I'll create a new inherited scene, your inherited scene commands, actor command. And I will call this the no actor command. You can call this a new actor command, but I will call this just no. And we will extend this script. So we will extend the actor command script. And instead of save this here, I will save it. Let me actually just save the scene, because it will be better. So I will save this on the no folder here. So we'll have the no actor command scene. And let's extend this script to have a no actor command class. Okay, so if we go here in the actor command, which is basically just an interface for the actor commands, we have a execute and an unexecute method. So let's copy these methods there. If you think about it, basically the interface that we have here, because it's not an actual interface, it already applies the no behavior or a behavior that doesn't do anything, because we are just passing when we call these methods. But just for understanding this no object pattern, let's go back to the no actor command. And instead of having this pass, which is used in the parent class for just abstract the methods that it shouldn't show have, we will instead just have some doc strings here that says that this doesn't do anything. And the same thing down here. So copy this and paste it. And there we have we'll have the no actor command object. Back to the actor, let's create a button here that will receive this no command. You can think about this pattern as something that you can implement an interface or something like this, because the no object will not do anything. So it just like if you are just making a concrete class, there is just the interface. So you don't do anything, but you can use it as a concrete implementation of the interface. So if I go here and add a new button, so I will just duplicate this and say nothing, oops, say nothing here. And this nothing will receive the no command. So let's go back here, drag and drop this here. And there we have it. So we have the nothing command here, drag this here, maybe here. So this will be something like nothing. So when we press this, the character will not do anything. You can say that this will basically just tell the character to wait. But this weight behavior is not contained in the command. So it's not something that the command does. The command doesn't do anything. But since we implemented this command queue to wait for 0.5 seconds, we can say that it will make the character wait. But note that this behavior is not a part of the new command. This is a part of other class that doesn't have to do anything with the new command. But in the new command itself, it doesn't do anything. So we can use it as being just a placeholder for something or basically for something that doesn't do anything. You can think about it like that. If you want your character to not perform something. So let's say at some point, you pick a debuff or something like this. And the character cannot move anymore. You can just place a new command here in each of these buttons. And the player will not be able to walk for some time. Then you can go back and inject the previous command back into these buttons. But I will save this. Let's go back to the game. And now we have this up, left, down, right and do nothing. So if we play this, I will tell it to go to the right, right, down, nothing, up, left. So if you go here in the remote, we have the game, then the grid, the actor and then the command kill. So we will walk right, we will walk right again, down, then we won't do anything. Then walk up, walk left. So let's go back to the game itself and play it. And you see that we had a small delay there. So it's the new command being performed. So I will unplay this again. So we will have it backwards. And you can see that this new command was performed. So this is the new object pattern. So I think that this wasn't enough to understand the power of the new object pattern. So I will go back here in the actor. Let's try to understand why you should avoid new usage. If we don't have anything here, so let's say we just are trying to mock up this project. Let's say we are just designing the project. And we just want to see if the classes are behaving like they should, but we don't want to actually make an implementation, a hardcore implementation. So if you go here in the commands and in the wall command, let's say we have a very complex behavior that we will have to implement. But at this point of the development, we don't want to spend time thinking about implementation. We just want to see how is the relationship between two classes. So in this case, between the button class and the command class. So instead of having concrete implementations of the behavior that we are expecting, we can just create a new command. And since this new command will let me open the new command here. And since this new command will actually have the methods that we are calling into commands, we can say, okay, we don't want to actually see the character walking, or we don't want to actually see how the object behaves. We just want to see if these classes, if the button and the command kill and the commands are interacting as they should. So we can just make a new object and we drag and drop it to here. Because if we don't have an implementation of a command yet, so let's say we have this button, but we don't have anything to use here. So if we go here in the game and test it, we actually have a new value here. If we print this value, we will have a new value in this command variable. So if we try to execute this, we will have an error. See, we have a non-existent functional instance in base new. And this is the danger of the new value. Because sometimes we actually just want to see how something works, or we just want a default behavior, or we just want to actually have something in our logic. Because the concept of notness, the concept of not having something to work on is very dangerous. It's actually, we can say that this is a logic failure. You can say that your logic work if you expect that you are working with nothing. So let's say here, we are saying, let's say here, and we have a check for this. So if command is equal to no, we will return. Why are we checking for this? Why are expecting that we not have something to work on? You can see that this is a failure of logic. You can think about, hey, why do you create something that at some point don't have anything? Why you expect to not have something in this? You see how this new usage is dangerous, because it makes you think that your logic works. But if you at some point of your logic, of your code, you expect that you will add something and this something is not, doesn't exist, why are you checking for this? Because if you are calling this method, you should pass something to this. You should have something concrete that you will work upon. So it's basically a nonsense to say that to check if something is no, because if this is true, so if this comment is true, there is some failure in your logic. You are asking something to add, in this case you are adding a command, and this command is nothing. So why are you trying to add nothing into this? So this is nonsense. You can see how this doesn't make any sense. And this is it. Well, I hope you like this kind of discussion. I really enjoyed making this no object pattern, because this enlightened me in so many ways. I have many, many checks for no values in my codes. And I think that basically every single one of them could be replaced with a better logic. And I think that at some point I could even use the new object pattern. But anyway, if you have some doubts, or if you have questions, or if I said something wrong here, I have many other examples of the new object usage. So you can ask for them as well. For this, you can use the comments below. If you're liking this series of design patterns, leave a thumbs up. This will help me stay focused on making this kind of content for you. And also, if you like this, don't forget to subscribe as well, because then you will receive notifications when I release a new video about this kind of content. And by the way, if you really appreciate my work, if you really like what I'm doing here, you can support me by becoming one of my patrons, which by the way, let's welcome Francisco Diaz, my newest patron. Thank you so much for joining us. And this is it. I hope you enjoy it. Thank you so much for watching. Keep developing. And until next time.