SMKS | Object Oriented Programming 3 - Inheritance @_smks | Uploaded May 2015 | Updated October 2024, 5 minutes ago.
Suggest new or help me make more videos here: patreon.com/opencanvas
In this lesson, we are going to cover the object oriented concept of ‘Inheritance’ when working with our code. Now although it can be considered a good approach for code reuse, it’s not always the way to go, for reasons we will discuss later on. But for now, let’s use the game example of constructing a hypothetical player for our game called Riley, just to put it into practice.
For now and future lessons, we will be migrating from the Action script language, to Haxe (HACKS) and the OpenFL (OPEN F. L.) Flash API. Links can be found in the description. First of all, we want our player to have the properties: name, and the direction he is currently facing.
Lets give this player some methods: stand, walk and talk. Now in our main class - which is called first on compilation - we can create a new instance of Riley and call the methods. First we call talk, that requires no parameters. Then stand, passing in the parameter of the direction. Finally, walk, passing in the number of steps to take and in what direction.
When we build this project with the HTML5 target, we can see in the console our traced output. Great, so we've built a class and made a new instance of it. But with this game, we have two protagonists, and we've only built a class for one of them. We also need one for Jack. The exact same functionality is required. We want Jack to stand, walk and talk. So our first instinct is to create a new class called Jack, copy everything from Riley, and paste it into Jacks class file. We create a new instance of Jack, and we can see that we get the expected behavior in the console. The thing is, they both share the exact same code, the only differences between them, is their name. Riley, and Jack. Duplicate code exists, and you could see how this would be an issue if we introduced more protagonists. So what would be a possible solution to this? We can make use of ‘Inheritance’. With this, we can specify a ‘super class’ that both players can ‘extend’ from.
So first things first. Let’s create the super class. In this class, we want all the code that is relevant to both protagonists. We will call this super class ‘Player’. We copy and paste all the code from one of the existing players, and tweak it so it’s relevant. In this case, it’s not setting the name so we initialize it, but don’t set it. Now if we go back to our Jack and Riley classes, we can remove all the boilerplate code, leaving behind the constructor function and make the name change. When we call super in the constructor, it will call the constructor of its parent, this means we don’t have to trace the name of the player and the direction they are currently facing. Remember to call the super method after you have declared your attributes in the sub class. When we have made this change for both sub classes: Riley and Jack, you’ll see that even if we call them, they both work like before, as seen in the console.
As mentioned earlier, Inheritance can be suitable in some cases, and does promote code reuse and code organisation, but isn't always suitable. You’d usually begin each coding problem by constructing some form of inheritance hierarchy that may not actually be suitable for that certain situation. An example being a zoo park, with many types of animals. Your task is to design a class for each animal in that park, taking into account their attributes and behaviors. They have a tiger and a lion that can both jump. So you create a super class named Animal with a method ‘jump’ to cater for them both. We can now make a tiger and lion class, and extend from the animal super class. But what about an elephant? They can’t jump, so if we create a new elephant class and extend from animal, it’s not relevant. In a situation like this, we need to consider ‘Composition over Inheritance’, something we will discuss in the next lesson.
Haxe: haxe.org
FlashDevelop: flashdevelop.org
OpenFL: openfl.org
References:
variadic.me/posts/2014-03-28-composition-over-inheritance.html
blogs.perl.org/users/sid_burn/2014/03/inheritance-is-bad-code-reuse-part-1.html
Follow me: twitter.com/shaunmstone
Suggest new or help me make more videos here: patreon.com/opencanvas
In this lesson, we are going to cover the object oriented concept of ‘Inheritance’ when working with our code. Now although it can be considered a good approach for code reuse, it’s not always the way to go, for reasons we will discuss later on. But for now, let’s use the game example of constructing a hypothetical player for our game called Riley, just to put it into practice.
For now and future lessons, we will be migrating from the Action script language, to Haxe (HACKS) and the OpenFL (OPEN F. L.) Flash API. Links can be found in the description. First of all, we want our player to have the properties: name, and the direction he is currently facing.
Lets give this player some methods: stand, walk and talk. Now in our main class - which is called first on compilation - we can create a new instance of Riley and call the methods. First we call talk, that requires no parameters. Then stand, passing in the parameter of the direction. Finally, walk, passing in the number of steps to take and in what direction.
When we build this project with the HTML5 target, we can see in the console our traced output. Great, so we've built a class and made a new instance of it. But with this game, we have two protagonists, and we've only built a class for one of them. We also need one for Jack. The exact same functionality is required. We want Jack to stand, walk and talk. So our first instinct is to create a new class called Jack, copy everything from Riley, and paste it into Jacks class file. We create a new instance of Jack, and we can see that we get the expected behavior in the console. The thing is, they both share the exact same code, the only differences between them, is their name. Riley, and Jack. Duplicate code exists, and you could see how this would be an issue if we introduced more protagonists. So what would be a possible solution to this? We can make use of ‘Inheritance’. With this, we can specify a ‘super class’ that both players can ‘extend’ from.
So first things first. Let’s create the super class. In this class, we want all the code that is relevant to both protagonists. We will call this super class ‘Player’. We copy and paste all the code from one of the existing players, and tweak it so it’s relevant. In this case, it’s not setting the name so we initialize it, but don’t set it. Now if we go back to our Jack and Riley classes, we can remove all the boilerplate code, leaving behind the constructor function and make the name change. When we call super in the constructor, it will call the constructor of its parent, this means we don’t have to trace the name of the player and the direction they are currently facing. Remember to call the super method after you have declared your attributes in the sub class. When we have made this change for both sub classes: Riley and Jack, you’ll see that even if we call them, they both work like before, as seen in the console.
As mentioned earlier, Inheritance can be suitable in some cases, and does promote code reuse and code organisation, but isn't always suitable. You’d usually begin each coding problem by constructing some form of inheritance hierarchy that may not actually be suitable for that certain situation. An example being a zoo park, with many types of animals. Your task is to design a class for each animal in that park, taking into account their attributes and behaviors. They have a tiger and a lion that can both jump. So you create a super class named Animal with a method ‘jump’ to cater for them both. We can now make a tiger and lion class, and extend from the animal super class. But what about an elephant? They can’t jump, so if we create a new elephant class and extend from animal, it’s not relevant. In a situation like this, we need to consider ‘Composition over Inheritance’, something we will discuss in the next lesson.
Haxe: haxe.org
FlashDevelop: flashdevelop.org
OpenFL: openfl.org
References:
variadic.me/posts/2014-03-28-composition-over-inheritance.html
blogs.perl.org/users/sid_burn/2014/03/inheritance-is-bad-code-reuse-part-1.html
Follow me: twitter.com/shaunmstone
