 This video was brought to you by my patrons. Thank you so much for your support. Hello there. In this video, we will continue the series about the four pillars of object-oriented programming. And in this video, we will talk about abstraction. So in the previous one, we talked about encapsulation. And now we will talk about the first step actually into designing a class. There is to abstract the class into the context of your application. But before diving to how we can use abstraction in Godot Engine, I will open a book so we can have a brief definition of what abstraction is commonly described as. So I will go to this book here. And here it is described as a model of a real-world object or phenomenon, limited to a specific context. This is a very good definition, but I will actually just take root of this real-world object. Because more than often, we work with just our imagination. So we want to abstract an object that doesn't have a real-world reference. So I will actually use abstraction as a model of an object or phenomenon, limited to a specific context. And this is very important to know because what you are going to achieve with abstraction is to take root of everything that is not relevant to the context of, let's say, your game. And just use what is relevant to it. So here I have in Godot a black hole. But we know that black holes are very complex objects, right? But to the context of my game, I just want to represent a black hole in such a way that it would communicate to the player that it will suck the mouse towards its center. I don't have to model the whole representation of a black hole because it's meaningless to the context of my game. I don't want to have all the physical properties of a black hole. So abstraction is a part of the designing process of a class. We will take root of everything that's not relevant that would make the application more complex that it should be. And we'll just cherry pick what is relevant to it. So the application has a goal. And we'll just use the properties and the behaviors of the object or the phenomenon that will make this goal achievable. So now let's try to abstract the sliding panel so we can see how we can use some traits of abstraction in Godot Engine. So I will close this black hole here. Don't save. And well, I will start using a simple panel class, a simple panel node. And well, since this will be an abstract sliding panel, I will prepend these words to communicate to whoever is trying to use this class that this is an abstraction of a sliding panel. It's not the concrete implementation of this sliding panel. Whoever is trying to use this sliding panel will have to implement its behavior. So I will prepend the word abstract to communicate that this is not a concrete class followed by the sliding to communicate that this is a sliding panel. It's not a common panel. And well, to slide, I can use an animation player, but I have some problems with animation players because they use absolute offsetting. And this can cause some bugs. So I don't like to do that because it's a static implementation of a sliding. And instead, I will use a twin because with twins we can take the current value of the properties of the object in runtime and use them to calculate the animation. I will also add a timer because I want the sliding panel to have a small delay between sliding in and out the screen. Now we have a sort of an abstract sliding panel. It doesn't have any behavior yet, but we have here what we need to start working with it. So if we have an engineer working with this class, it will know that, well, we will use a string and a timer to implement some of the behaviors of this sliding panel. So I'll save this class into the interface folder here, abstract sliding panel. So I will add a new script here so we can see the abstraction features that are going to provide to us so we can make sort of an abstract class. So I will create a script here and let's start abstracting this class now. So I'll take rid of these defaults here. And for the context of the game, I just want this sliding panel to slide in and out the screen. And for that, I think that I will only need three properties. I will export a vector 2. That will be the direction of this slide because maybe I can slide in so it will point down. Maybe I can slide out pointing up. Maybe I can slide on the left, on the right. So it's good to have this direction pointing. Where is the direction that this slide will happen? And by default, it will be sliding down. I will also need a float. Then what will be the duration of this sliding? Because with that, I can define how long will take the sliding. So duration, by default, it will take one second. And also I will have a distance, the distance of this sliding, right? So export float var distance, which by default will be 100 pixels. So here we have the properties that this sliding panel will have. And now let's try to describe its behaviors. With that, we will not describe how it will behave. But what are the behaviors? This is what is concerned in the abstraction phase of the designing of a class. We are not concerned with the implementation yet. We are not concerned with how it will behave. How will the behave happen? We are just concerned about what are the behaviors of this class. So in the case of the sliding panel, I will have a function that will tell it to slide. I don't know if I add slide in and out, or if I just add a mode. Maybe I can have a mode here that will be... I will add an enumerator, mode in and out. And then I will export a mode variable that will be the mode. And by default, it will be mode.in. So now I think that this sliding panel will only have this slide method. Because I think that this is basically the only thing that it does. We will try to follow the single responsibility principle that tells that a class should be concerned with one thing and one thing only. So to do that, I will describe here on the top that this is a panel that slides on the screen. And with that, we have a single responsibility to this class. And we will have here this slide method. If you leave a method blank like this, we will have some errors, right? Godot will tell that it is expecting a block inside of this function. But as I said, when you are abstracting a class, when you are just concerned about the design of the class, you are not concerned with the implementation yet. This is a part of the engineering of the class. Godot offers to us the ability to leave a method blank by using the keyword pass. This will tell the compiler or the interpreter that this function doesn't have anything and there is no problem with leaving this function blank. With that, we can focus back on the designing of the class and not on the implementation, so we can leave it like that. But if you want to make sure that an engineer will override this method, it will implement this method, making sure that this method will not be blank, you can use the keyword assert, always passing false. And I think that you can add a comment here to communicate to the engineer that this is a virtual method and shall be overwrite by children classes. So when the engineer called this method on other classes or maybe on this class, so if he ignores that this is an abstract sliding panel, this is an abstract class, when he calls this slide method, the compiler will fail because this will assert always false and it will bring the engineer to this line of code here, the line 19, and he will see that this is a virtual method and shall be overwrite by children classes. So you are designing the class to make sure that on further implementation, someone will have to override this. But abstract classes are not just meant to be used for, let's say, for designing. They are also used to provide an interface to interact with its children. So let's say when an engineer tried to implement this abstract class, let's say a concrete sliding panel overriding this slide method here, anyone that will use this concrete implementation of the sliding panel will know how is the signature of this slide method. If it has arguments or not, what are the properties of this class, what are the behaviors and the features that this class has, what it is intended to be used for just by opening the abstract slide script. So they don't have to be concerned about the implementation itself. They don't have to open a complex version of the sliding panel. They can open the abstract class and have an easy interface to interact and to understand what this class is meant to be used for. So this is the power of abstract classes to provide an interface to the user. I received some comments in the previous video that maybe I misunderstood or I confused abstraction with encapsulation. But let me describe the two in my words so we can understand how I differ both. So to me, encapsulation is to make the implementation of the class easy to understand while abstraction is to design the class into the context of the application only taking relevant pieces of it. And well, an abstract class provides an interface to interact with the class. But the encapsulation is to make this implementation easy to understand. So this is the difference for me. But if you still have some doubts or if I say something wrong or maybe something is not clear yet, please leave a comment below. I will be modding happy to be corrected to understand if I am going into the wrong direction or if I am on the right path. Let me know. Leave a thumbs up if you enjoyed the content. This will help me understand that I'm going to the right path. And also if you want to get more of this content, don't forget to subscribe and to turn on the notifications so when I release a new video on this content you will be notified. And also if you enjoy this kind of content, if you enjoy the work that I do consider becoming one of my patrons so you can support me in this journey. But that's it. Thank you so much for watching. Keep developing and until the next time.