Java with Pokemons Object Oriented
–
Programming - J Ajendra
First Edition. Could very well be the last.
Copyright © 2016 J Ajendra
All rights reserved. Though I wonder what one would ever achieve by copying the text from this document. Yet, for undoubtedly imaginary legal purposes and to make this book look a bit professional, I have decided to waste 3 minutes of my apparently pointless life, in drafting this page.
1
First Edition. Could very well be the last.
Copyright © 2016 J Ajendra
All rights reserved. Though I wonder what one would ever achieve by copying the text from this document. Yet, for undoubtedly imaginary legal purposes and to make this book look a bit professional, I have decided to waste 3 minutes of my apparently pointless life, in drafting this page.
1
To, Aishwarya and Vivek Wishing you a very happy married life!
Table of Contents INTRODUCTION .................................................................................... 1 CLASSES AND OBJECTS ....................................................................... 2 ENCAPSULATION .................................................................................. 7 INHERITANCE .......................................................................... ........... 14
Protected Access Modifier .............................................................. 17 Instanceof Operator......................................................................... 22 Types of Inheritance ........................................................................ 26 Diamond Problem ..................................... ........................................................................... ...................................... 28 POLYMORPHISM ...................................................................... ........... 32
IS – A Relationship ................................................................ .......... 32 Method Overriding ......................... ......................................................................... ................................................ 33 Method Overloading....................................................................... 38 Constructor Overloading ............................................................... 41 Casting ...................................................................................... ........ 44 ABSTRACTION .................................................................................... ......... ........................................................................... 46
Abstract Classes ............................................................................... 46 Interfaces ............................................................................... .. ............................................................................. ........... 49 APPENDIX A ............................................................................. ........... 53
Reference Type and type of an Object .......................................... 53
INTRODUCTION Folks,
S
ince you have started reading this book, I take it that you know basics of programming and stuff like function calls and loops. If not, pick this book up after you are a bit familiar with all that. OOP is a fascinating topic and sadly, most of the explanations expla nations and examples available on internet are a tad boring. Trust me, I learned from those and at time, fell asleep. So this is a humble attempt to make learning interesting. Thanks to amazing yet a bit buggy game by Niantic, the Pokemon craze has taken the world by storm. If by any chance, chance , you have been leaving leav ing under the rock and haven't heard of PokemonGo or Pokemons for that matter, please feel free to play the game for few days. Try to watch a couple of Pokemon episodes as well! (PS. I prefer Indigo league) Anyway, we are about to dive into the world of OOP with the help of these imaginary creatures. I am taking the liberty of assuming that you are familiar with the following concepts: 1. 2. 3. 4. 5. 6.
Basic Classes & Objects Primitive Data Types Constructors Function calls Loops Other procedural programming concepts not related to OOP.
Also, this book covers the most fundamental topics related to OOP. Some interesting concepts like covariant returns or Constructor chaining are skipped due to sheer boredom and laziness on author’s part. Off we go!
1
CLASSES AND OBJECTS had absolutely no intention of going over classes and objects, but lucky for you, my cat just won’t stop purring and for love of God, I cannot fall asleep. So we will quickly rush through the basics. Since the book title claims to be somehow related to pokemons, let’s start with that. Now, what are the things that describe a pokemon? Amongst many, some are - nick name, type, HP, CP, height, weight, etc. Don't take my word for it - consult Pokemon Go.
I
Fig 1.1 Great. Now let’s note down what a pokemon can do. It can go in the Pokeball, come out of the Pokeball and attack. Yep that’s it for now. Equipped with all this information, we get an overview of a pokemon.
2
Fig 1.2 Ladies and gentlemen, a java code representation of the above information is known as a Class. In desperate attempt to make my cat quiet down, we will dedicate this chapter to the Cat God Bastet, by using pokemon Persian in our first example. All Hail Bastet! public class Persian{ String nickName, type; int HP,CP; float height,weight; public void comeBack(){ // come back in the pokeball } pubic void iChooseYou(){ 3
// We know what that means } public void captivate(){ // Its an attack move. you better duck this one }
Basically, a class can be defined as a template that describes state and behavior of an object of this class. What it means is, we can create an Object bastet from the above classPersian bastet =new Persian();
And set the following values for the object: bastet.nickName="Her Highness"; bastet.type="Goddess"; bastet.HP=40;
And so on. We can call the methods likebastet.comeBack(); bastet.iChooseYou(); bastet.captivate();
Objects, like bastet, have a state that is different from other objects of the same class. For example, if we create another object of Persian classPersian thunderCat=new Persian();
And set attributes of thunderCat (completely arbitrary values of my own choice): thunderCat.nickName="Thunder"; thunderCat.type="Normal"; thunderCat.HP= 20;
And so on. 4
Similar to bastet object, we can call the methods on thunderCat object too. thunderCat.comeBack(); thunderCat.iChooseYou(); thunderCat.captivate ();
The data contained by both thunderCat and bastet is different, even when they are objects of the same class. So basically, a class defines the attributes that an object can have and actions it can perform, but the actual value of those attributes are set by the object and are restricted to that object only. This allows multiple objects of the same class to be created containing different values.
Fig 1.3 And I bet you already knew all that. Anyway, all I really wanted was to show off my pokemons. Next up is Access Modifiers. Access Modifiers are a bunch of keywords that can be used to restrict the access to classes, data members (Instance variable) and member functions (methods). Each access modifier
5
allows an instance variable and a methods to be available in a certain scope, as shown below -
Fig 1.4 Can you guess what will be accessible in which scope in the following code? public class Persian { public String nickName; String type; private int CP; protected int HP; public void setCP (int cp){ } void setHP (int hp){ } private int getCP ( ){ } protected int getHP (){ } }
I know it makes no sense to use the modifiers this way for some variables and methods, but the point here is to understand the scope. Also, we will be dealing with protected modifier a lot while studying inheritance.
6
ENCAPSULATION
E
ncapsulation in Java is a mechanism of wrapping the data (variables) and code acting on the data (methods) together as single unit. Basically, it means we have to design our class in such a way that the only way any other class can access our data members is using methods. And why exactly your boss makes you do this extra and tedious work? Let’s take a look. We have two pokemons - Electabuzz (Electric) and Crabby (Water). And these pokemons are in a very intense battle at the moment. For the sake of simplicity, let’s only consider their HP. public class Electabuzz { int HP; } public class Crabby { int HP; }
Being a great pokemon trainer that you are, you wrote the classes for all 151 pokemons by yourself (Kudos). And the one who wrote the code for battle simulation is none other than your friend Bob. Now Bob has a bone to pick with you since you stole his lunch money. So he writes his battle simulation method code as public void battleSimulation(Electabuzz ebizz, Crabby crybaby) { ebizz.HP = -25; crybaby.HP = 182; // rest of the apocalyptic code }
Oops! Can you see the problem here? HP should range from 0 to 100, but nothing is stopping Bob from messing up our code by setting invalid values! So how do we make sure that other programmers who apparently couldn't 7
care less of your existence, don't mess up the code? Encapsulation to rescue! First, let’s make data member private. This will ensure that no one can directly assign value to it. Now, we want others to be able to get the value of data member, so we write a get function and return the value. Finally, we want to allow others to set only valid values to our data members, so we write a set function and validate the input before setting the value. And make our getters and setters public. Sounds fun right? Let’s try it. public class Electabuzz { private int HP; public int getHP(){ return HP; } public void getHP(int h){ if(h>=0 && h<=100) HP=h; } }
There you go! You have perfectly encapsulated our dear little Electabuzz. Oh, I almost forgot - there is another perfect lifesaving reason to encapsulate your classes. Imagine we are still going by our previous implementation (Silly, I know). And Bob, still pissed at you, sets a negative value to HP variable and is laughing his heart out somewhere. Now that cute programmer you have a crush on, Alice, is using the HP variable to do some rocket science computations. Due to Bobs prank, the values that Alice is computing are way out of the error margin, and she is not happy. Along with Alice there are many more developers whose code broke thanks to your HP value and they are out for blood. Oh and mind you, they will find your address and hunt you down! So to save your neck, encapsulate all your classes and lead a stress free life! Not to mention, once other programmers are using the method to access variables, they don’t care what you write inside the methods as long as your 8
method signature doesn't change and it returns a valid value. Hell, you could go like public void setHP(int h){ if(h>=0 && h<=100) HP=h*2; } public int getHP(){ return HP/2; }
And no one would care. This allows you change your implementation whenever you want, thus making your code extensible, flexible and maintainable. Also, if you don't want anyone to modify the value of your precious little variable, simple don't provide the setter for it! This ensure read-only access to that variable. Similarly, you can provide write-only access by not providing the getter. (Though I am not sure why you would want to do t hat) With encapsulation, you gain the magical ability to change your implementation without breaking the code of others. Now that we are here, let’s jot down the benefits of encapsulation: The fields of a class can be made read-only or write-only. A class can have total control over what is stored in its fields. The users of a class do not know how the class stores its data. A class can change the data type of a field and users of the class do not need to change any of their code.
Before we move on, take a look at the encapsulation in a nut-shell:
9
Fig 2.1 Finally, we are at the last point in Encapsulation. So buckle up. public class Stats { private int attack; private int defense; private int speed; public Stats (int a, int d, int s){ attack=a; defense=d; speed=s; } public String toString(){ return "attack "+attack+" defense "+defense+" speed "+speed; } //Assume getters and setters here }
And a properly encapsulated class 10
public class Psyduck { private String name; private String type; private Stats stats; public Psyduck(){ stats = new Stats(10,5,6); } // Assume getters and setters } public class Tester{ public static void main(String args[]){ Psyduck psy=new Psyduck(); System.out.println(psy.getStats()); } }
We have a class Stats which defines some statistics about the pokemon. Psyduck has an object of Stats and initializes it in constructor. The output produced by Tester class would be - attack 10 defense 5 speed 6. So far so good. Notice how Tester class is used getStats() method instead of directly accessing the stats object like - psy.stats Let’s modify our Tester class a little and see what happens. public class Tester{ public static void main(String args[]){ Psyduck psy=new Psyduck(); Stats statsObj=psy.getStats(); System.out.println(statsObj); - Output 1 statsObj.setAttack(290878); System.out.println(psy.getStats()); - Output 2 } }
Output 1 prints: attack 10 defense 5 speed 6 and Output 2 prints... wait for it … attack 290878 defense 5 speed 6 11
Well, good news is that we used setAttack() method to set the value, but do you see a big problem here? Let me give you a hint. It’s this lineStats statsObj=psy.getStats();
Figured out? Getters are supposed to provide read-only access, yet we are able to modify the value of Psyducks stats without using setter at all! So what’s happening here exactly? If you are as confused as the poor Psyduck, let’s take a look in heap memory.
Fig 2.2 This statement: psy.getStats(); returns an reference to the Stats object. Even though this is a copy of a reference, the reference itself is pointing to the original Stats object in the heap! Hence any operations done on the object using this reference variable, will change the original object. So our simple encapsulation fails here. A way to deal with this is to actually create a new Stats object having the values of Psyducks Stats, and return the reference to this object. Your getter for stats would look something like this. 12
public Stats getStats(){ Stats temp=new Stats(this.stats.getAttack(),this.stats.getDefense(), this.stats.getSpeed()); return temp; }
And in heap:
Fig 2.3 Remember this for all the getters that are returning an object reference, be it an actual object, an array or even a StringBuffer. Now, we are finally done with encapsulation.
13
INHERITANCE
L
et's take a look at some of the classes we created till now: public class Persian{ String nickName, type; int HP,CP; float height, weight; public void comeBack(){ } pubic void iChooseYou(){ } public void captivate(){ } // setters and getters for all the fields. } public class Electabuzz{ private String nickName, type; private int HP,CP; private float height, weight; public void comeBack(){ } pubic void iChooseYou(){ } pubic void thunderbolt(){ } // setters and getters for all the fields. } public class Squirtle{ private String nickName, type; private int HP,CP; private float height, weight;
14
public void comeBack(){ } pubic void iChooseYou(){ } pubic void waterGun(){ } // setters and getters for all the fields. }
I know you guys are smart and you have already figured out the problem here. But just to be on the same page, its - Code duplication. We are writing too much code! Imagine we were to continue using this approach for all 151 pokemons in Indigo league, and then you decide to change HP from int to float, or change the implementation of comeBack() method. We will end up wasting next two days of our precious little life, changing all the 151 classes. Shall we try to get rid of this problem? This is where Inheritance comes into the picture. So here's what we are going to do: 1. Move all the duplicate code to a common class (may be class Pokemon?) 2. Create Pokemon specific classes such that it contains fields and methods of the common class while implementing its specific code as well. When you inherit from an existing class, you can reuse methods and fields of parent class (Pokemon), and you can add new methods and fields in the base class (say class Pikachu?). Moving common code to Pokemon class: class Pokemon{ private String nickName, type; private int HP,CP; private float height, weight; 15
// All setters and getters public void comeBack(){ } pubic void iChooseYou(){ } }
When a class Pikachu inherits from the class Pokemon, the definition of the class Pikachu becomes: class Pikachu extends Pokemon{ pubic void thunderbolt(){ } }
class Pikachu extends Pokemon - what this line implies is that all the fields and methods of pokemon class are part of Pikachu class as well and hence they are accessible to it.
Fig 3.1 16
So if we create an object of Pikachu now, it would be: Pikachu pika = new Pikachu(); pike.setHP(10); // inherited from pokemon pika.comeBack(); // inherited from pokemon pika.thunderbolt(); // attack specific to Pikachu class.
So basically, our code in Pokemon class will be reused by every other class that extends Pokemon. If tomorrow we decide to change the implementation comeBack() method, all we need to do is make change in the pokemon class and everything will be fine in our little java universe. Inheritance is used to address two things: 1. Code reuse 2. Polymorphism We have already dealt with code re-usability and we will take a look at polymorphism in a while. For now, let’s drill into inheritance a bit more.
Protected Access Modifier Well, back in the Introduction chapter, I promised, against my better judgment, that we will learn about protected access modifier in Inheritance. Please remind me never to make any promises while drunk. Anyhow, let's take a look at one of the most misunderstood access modifiers in Java.
17
Fig 3.2 A protected access modifier is almost similar to default modifier. Default member and functions are accessible in the class and Package. Since all access modifiers are accessible in the same class, no point in making a big fuzz about it. So for the sake of understanding, let's say that default modifier provides package restriction. Any other class outside the package of the current class will not be able to access anything that current class had marked default. For the classes outside the package, all default members and functions are considered to be private. If you think this is confusing, then you better start praying to God Anubis as the protected modifier is the king of confusions. But fear not, we will try to make it as simple as possible to understand. A default member may be accessed only if the class accessing the member belongs to the same package, whereas a protected member can be accessed by a subclass even if the subclass is in a different package. What this means is, protected modifier is a bit considerate of parent-child relationship. When a subclass is in a different package, it can access its parent's default members and functions only through inheritance. (We will look at this in a bit) When you think of default access, think package restriction. But when you think protected, think package + children.
18
protected access modifier focuses on two factors : Packages and Subclasses Facts about the fields or methods of a class that are marked protected are: 1. They are accessible to all classes within the same package. 2. They are accessible to all subclasses irrespective of the package of the subclass
For example: we have package parent; class Pokeball{ protected int catchRate; }
// protected data member
Case 1: Any class in the same package package parent; class CatchPokemon{ void usePokeball(){ Pokeball p=new Pokeball(); System.out.println(p.catchRate); } }
Since classes Pokeball and CatchPokemon are in the same package, we can create an object of Pokeball and access catchRate data member. Case 2: Any Class in different package package child; class GreatBall { void setCatchRate(int cr){ Pokeball p=new Pokeball(); p.catchRate=cr; // compiler can’t find catchRate. 19
} }
Since classes Pokeball and CatchPokemon are in the different package, catchRate acts as a private member for GreatBall and hence cannot be accessed. Case 3: Any Class in different package that extends from Pokeball package child; class UltraBall extends Pokeball{ void setCatchRate(int cr){ catchRate=cr; // Compiler doesn't even flinch. } }
Since UltraBall is extending from Pokeball, all data member of Pokeball (except private) also becomes data members of UltraBall. So we can simply access catchRate as if it’s a data member of UltraBall. So far so good. But what happens when we do package child; class UltraBall extends Pokeball{ void setCatchRate(int cr){ catchRate=cr; //all good - inherits from parent Pokeball p=new Pokeball() p.catchRate=cr; // Compiler is furious } }
Even when UltraBall inherits from Pokeball, creating an object of Pokeball and accessing default member is a No-Go. Since creating an object and trying to access the data member has nothing to do with inheritance, this becomes a classic case 2. 20
Hence we said something like this before –‘When a subclass is in a different package, it can access its parent's default members and functions only through inheritance’. Hopefully it’s clear now. If not, feel free to perform black magic on the kind folks at Sun Oracle. Just one last point before I wrap this up. Consider the following piece of code. package parent; class Pokeball{ protected int catchRate; }
// protected data member
package child; class UltraBall extends Pokeball{ public int size; void setCatchRate(int cr){ catchRate=cr; // inherits from parent } }
Now, UltraBall class has two data members - size and catchRate (Inherited from Pokeball) class CatchPokemon{ void usePokeball(){ UltraBall ub=new UltraBall (); System.out.println(ub.size);
// Works perfectly as size is public member of UltraBall System.out.println(ub.catchRate); // And the great compiler is displeased. } }
21
What happened here is - when UltraBall inherited a protected data member (catchRate) form its parent (Pokeball), catchRate became a private data member of UltraBall class. Hence any other class cannot use catchRate from an object of UltraBall, unless the class extends from UltraBall. In that case, catchRate in this new class is accessible only by inheritance (case 3) and becomes a private data member of this new class. Whew! That wraps up protected modifier. Lucky for you, it is used in very special cases and you won’t probably see it much.
Instanceof Operator Before we dwell into the instanceof operator, let's first understand IS-A relationship. When a class inherits form other class either by extending the class or implementing the interface (stay tuned for this one), it is said that the base class IS-A type of Parent class. In our example: Pikachu IS-A Pokemon as Pikachu extends Pokemon. Pokemon IS-A Object as every class implicitly extends form Object class Pikachu IS-A Object as Pokemon IS-A Object and Pikachu IS-A Pokemon Note: In Java every class implicitly extends from Object class. Hence the methods of the Object class such as equals(), notify() and others are accessible to every other class.
IS-A relationship is a uni-directional relationship. i.e. Every object of Pikachu IS-A Pokemon, but every Pokemon need not be Pikachu. A Pokemon can be Onix as well right?
22
Fig 3.2 So what does this mean? Since Pikachu IS-A Pokemon, a reference of type Pokemon can hold a reference to Pikachu object. Pikachu pika=new Pikachu(); Pokemon anyPoke=pika;
Woah! Let's see what’s happening here. Reference type (Appendix A) of anyPoke object is a Pokemon and it is holding a reference to Pikachu object. Why does the compiler allow this? Well, the compiler says, since Pikachu is extending Pokemon, all the fields and methods in Pokemon class are definitely present in Pikachu class. So saying pika.comeBack(); and anyPoke.comBack();
Are one and the same thing, as the comeBack() method is defined in Pokemon class. What if we try to call the method specific to Pikachu class? pika.thunderbolt(); // works fine
23
anyPoke.thunderbolt(); // Compiler can’t find this method in Pokemon class, so it fails to compile.
Alright, it makes sense why compiler would allow this, but why would we, as a coder, want to do this? Let's introduce a Pokemon Trainer - Ash. class PlayerAsh{ }
Now Ash wants to call his pikachu and charmander back class PlayerAsh{ void pikachuComeBack(Pikachu p){ p.comeBack(); } void charmanderComeBack(Charmander c){ c.comeBack(); } }
And if he had 10 more pokemons, we will end up writing the methods for all pokemons. But wait, comeBack() method is a common method defined in Pokemon Class. So it doesn’t matter if we write p.comeBack(); or c.comeBack(); same code will be called. Now since both Pikachu and Charmander IS-A Pokemon, and compiler allows us to use Pokemon reference type to hold reference of objects of its child classes, we can rewrite the PlayerAsh class as: class PlayerAsk{ void pokemonComeBack(Pokemon p){ p.comeBack(); } }
24
So irrespective of whether the pokemon is Pikachu or Charmander or Evee, this one method works for all. Hurray for us! Now let’s say, we have an object of Charmander referred by Pokemon reference typePokemon charmander=new Charmander();
Now, if we want to call ember() method of charmander obj, we won’t be able to do so as long as the object is referred to by Pokemon reference type. charmander.ember(); // Compiler can’t find this method in Pokemon class, so it fails to compile.
What we can do, is cast the object back to Charmander reference type: Charmander cd = (Charmander)charmander; // This is called as downcasting
Now cd.ember(); works like a blazing fire! But wait, what if we are getting our Pokemon from some other code? How are we to know that our Pokemon reference type has a Charmander object? If it’s our arch enemy Bob sending us the object reference, it’s possible that he has set something up to mess up our code. Say for example, Bob sends a Pikachu object with reference type of Pokemon. Then Charmander cd = (Charmander) anyPoke; // anyPoke is a Pikachu object cd.ember();
The code would compile just fine, but if will burst like a volcano at runtime throwing a ClassCastException. 25
To protect our code from such unexpected eruptions, we use an instanceof operator. if (anyPoke instanceof Charmander) { Charmander cd = (Charmander)anyPoke; cd.ember(); }
instanceof keyword is a binary operator used to test if an object (anyPoke ) is a subtype of a given Type. instanceof operator only works for the classes in hierarchy. anyPoke is an instance of Charmander class. So if (anyPoke instanceof Charmander) returns true. Since Charmander class extends Pokemon, if (anyPoke instanceof Pokemon) also returns true. But if anyPoke is an object of Pikachu, then if (anyPoke instanceof Charmander) returns false as Pikachu is not of the type Charmander. Remember, in inheritance, every time we cast an object, check it using instanceof operator to avoid runtime exceptions.
Types of Inheritance Now that we have a basic understanding of inheritance, let's take a look at the types of inheritance supported by Java. And this time, we will be taking some help from Team Rocket.
1. Single Inheritance
This is your most basic inheritance and is too simple for a smart person like you. Single inheritance means one class extending another class. By now, you must have become an expert in this type, provided you didn't sleep
26
through the chapter. For the sake of consistency, an example would be, Meowth extends Pokemon.
Fig 3.3
2. Multi-level Inheritance
Multi-level inheritance is the one where one class extends another which inturn extends another which in-turn can extend another and will finally give you a headache. Following diagram will explain it better than mere words.
Fig 3.4 27
3. Hierarchical Inheritance
In such kind of inheritance one class is inherited by many sub classes . Class Pokemon is inherited by Meowth, Ekans, Koffing etc. Go Team Rocket!
Fig 3.5
Diamond Problem The thing is, in Object Oriented Programming, there are two more types of inheritance. But the almighty creators of Java decided not to support them for the reasons we will soon look into. But first let's see what these types of inheritance are:
1. Multiple Inheritance
In this type, one class inherits from two or more classes. Simple enough? Not when we'll understand the problems of this design.
28
Fig 3.6 We can’t attempt to do this in Java, but if we were to try, code would be something like this. class BabyNidoran extends Nidoking, Nidoqueen{ }
2. Hybrid Inheritance Hybrid inheritance can be created using Hierarchical and Multiple inheritance. A base class inherits from two or more classes and those classes inherits from the same parent class.
Fig 3.7 29
This brings us to the infamous Diamond Problem. Evidently, the above diagram looks like a diamond, hence the name. Consider the following code: class Nidoking{ public void poisonSting(){ //attack take out 20 HP of the opponent } public void comeBack(){ // Inherited from Pokemon Class // goes into UltraBall } } class Nidoqueen{ public void poisonSting(){ //attack takes of 30 HP of the opponent } public void comeBack(){ // inherited from Pokemon Class // goes into GreatBall } } class BabyNidoran extends Nidoking,Nidoqueen{ }
Now BabyNidoran is inheriting a method poisonSting from Nidoking which takes out 20 HP. But BabyNidoran is also inheriting the same method from Nidoqueen where it takes out 30 HP. So, in the following code: BabyNidoran bn=new BabyNidoran(); bn.poisonSting(); // Compiler cannot determine which method to call.
30
Similarly, comeBack() method, which is inherited by both Nidoking and Nidoqueen is also indirectly inherited by BabyNidoran. Here, there will be an ambiguity if comeBack() method is called on BabyNidoran's object. Compiler won’t be able to decide if the BabyNidoran should go into UltraBall or GreatBall Due to this ambiguity, multiple inheritance and hybrid inheritance is not supported by Java.
31
POLYMORPHISM
G
rab a cup of coffee (or your choice of drug), because this one is going to need your brain working at full throttle.
Polymorphism technically means having several different forms. Remember Nymphadora Tonks from Harry Potter? A wizard who could change her form at will. Yep, that’s polymorphism. Though the term used in Harry Potter is Metamorphmagus. Never mind that. Polymorphism for us, in Java, is going to revolve around the methods. But for that, the necessary condition is Inheritance. We are getting a bit ahead of ourselves. Let’s refresh a few things first.
IS – A Relationship We looked over IS-A Relationship back in Inheritance. Any class that inherits - extends or implements (will look at this one soon) from other class satisfies this relationship. And since all classes implicitly inherit from Object class, all classes satisfy IS-A Relationship with Object class.
Fig 4.1 32
Here, Pokemon IS-A Object Bulbasaur IS-A Pokemon Squirtle IS-A Pokemon Pikachu IS-A Pokemon Bulbasaur IS-A Object Squirtle IS-A Object Pikachu IS-A Object And that’s about it. We will use this new -age foundation knowledge to understand the following concepts.
Method Overriding After much deliberation and long discussions with my guide and mentor, my Cat, I have finally decided to use a Mouse Pokemon, Pikachu, for this topic. Here are the classes we have defined so far (For the obviously lazy reasons, only the relevant code is written) class Pokemon{ private String nickName, type; private int HP,CP; private float height, weight; // All setters and getters public void comeBack(){ } pubic void iChooseYou(){ } } class Pikachu extends Pokemon{ pubic void thunderbolt(){ } }
33
Alright, now according to what we studied till now, Pikachu class contains almost (remember access modifiers?) everything present in Pokemon class. So we can peacefully write the following code. Pikachu pika=new Pikachu(); pika.comeBack(); //From Pokemon Class pika.iChooseYou(); //From Pokemon Class pika.thunderbolt(); //From Pikachu Class
For those who have seen the anime series of Pokemon (those who haven’t, please see it!), you might remember that Pikachu is one stubborn Pokemon who refuses to go in the Pokeball. For humoring you all, which seems like my job here, let’s make it so that when comeBack method is called on a object of Pikachu class, our code should say – ‘I am the great Pikachu and no Pokeball shall contain me.’ If Pikachu wasn’t inheriting from Pokemon class, our code would like: class Pikachu{ public void comeBack(){ System.out.println(“I am the great Pikachu and no Pokeball shall contain me.”); } pubic void thunderbolt(){ } }
Well, even with inheritance, all we have to do is write the same code! class Pikachu extends Pokemon{ public void comeBack(){ System.out.println(“I am the great Pikachu and no Pokeball shall contain me.”); } pubic void thunderbolt(){ } 34
}
Here, we are Overriding the comeBack() method form Pokemon class in Pikachu class. What this means is, whenever an object of Pikachu class calls comeBack() method, the implementation in Pikachu class gets executed. Pikachu pika=new Pikachu(); pika.comeBack(); //From Pikachu Class pika.iChooseYou(); //Still from Pokemon Class
This will display - I am the great Pikachu and no Pokeball shall contain me. The implementation of non-overridden methods, like iChooseYou, will remain the same as Pokemon class implementation. So that’s about it. The only big fuzz about overriding is that it is runtime polymorphism. i.e. JVM decides at runtime which comeBack() should be called, whether the one in Pokemon class or the one in Pikachu class. And how does JVM decide this? You probably guessed it, depends on the Object type. Let’s take a look at some code. class Pokemon{ private String nickName, type; private int HP,CP; private float height, weight; // All setters and getters public void comeBack(){ System.out.println(“On my way ”); } pubic void iChooseYou(){ } } class Pikachu extends Pokemon{ public void comeBack(){ System.out.println(“I am the great Pikachu and no Pokeball shall contain me.”); } 35
pubic void thunderbolt(){ } } class Charmander extends Pokemon{ pubic void ember(){ } } Pokemon poke=new Pokemon(); poke.comeBack(); // On my way Pikachu pika=new Pikachu(); pika.comeBack(); //- I am the great Pikachu and no Pokeball shall contain me. Charmander charu=new Charmander(); charu.comeBack();// On my way
Ok, poke object executes comeBack() implementation of pokemon class, and so does the charu object. But since Pikachu class has overridden the comeBack() method, pika object executes the overridden method in Pikachu class. So far so good. Problem starts here. Going back to IS-A relationship, we know that Pikachu IS-A Pokemon. So reference type of Pokemon can refer to a Pikachu object. Consider the following code. Pikachu pika=new Pikachu(); Pokemon poke=pika;
Perfectly fine code, thanks to Inheritance. Now let’s see what complier thinks. Complier says, since Pikachu inherits from Pokemon, all the methods and data members of Pokemon are accessible in Pikachu. So reference type of 36
Pokemon can refer to Pikachu’s object as long as the methods or fields accessed by this object reference are existing in Pokemon class. Too big sentence. Let’s break it down. As far as compiler is concerned, if the reference type is pokemon, then at compile time, it can only access the methods / data members present in Pokemon class. So saying: Pikachu pika=new Pikachu(); Pokemon poke=pika; poke.thunderbolt(); // not going to work
Since Pokemon class does not contain thunderbolt() method, compiler won’t let you compile the above code. But saying: poke.comeBack();
is perfectly acceptable as Pokemon class contains comeBack() method. But can you guess the output of the above code? Its - I am the great Pikachu and no Pokeball shall contain me. Weird? What is happening here is, at compile time, compiler makes sure that comeBack() method is present in Pokemon class even though poke refers to Pikachu’s object. Compiler couldn’t care whether poke is referring to Pikachu’s object or Charmander’s object, as long they as satisfy IS-A relationship. But at runtime, the JVM sees that even though poke is of type Pokemon, it is referring to Pikachu’s object, so JVM executes the comeBack() method overridden in Pikachu Class. Hence the runtime polymorphism.
37
Fig 4.2 Wait, what if we want to call the parent’s method from the overridden method? Just use super.methodName(); For example: class Pikachu extends Pokemon{ //overridden method public void comeBack(){ super.comeBack(); // calls Pokemon Class’s comeBack method. } pubic void thunderbolt(){ } }
Finally! That was a big one. Take a short break and digest what the hell we just studied. Done? Now, Advance soldier!
Method Overloading Compared to method overriding, this is going to be a walk in a park. One thing to remember is, for method overriding, Inheritance is a necessity, but for overloading, such is not a case. Also, Overloading is compile time polymorphism. i.e. compiler determines which method will be called at
38
compile time itself. In overriding, JVM determines which method will be called at run time (hope you remember). To understand this concept. We are going to look at evolutions in Pokemon series (Not PokemonGo). Remember how pokemons used to evolve? It would depend on their battle experience and wait – for – it, stones! Consider dear little Eevee. It can evolve depending on the environment or by being exposed to stones. Now, if we were to write an evolve() method in our Eevee class, should we be writing two methods like evolve() and evolveUsingStone()? I guess not. We would rather overload the evolve() method. Here’s how it works: class Eevee extends Pokemon{ public void evolve(){ // natural evolution } public void evolve(Stone stone){ //evolution by stone } }
If you pay a tinee - tiny attention, you would notice that method name here is same – evolve(). What differs is parameters. Eevee vee=new Eevee(); vee.evolve(); // natural evolution vee.evolve(waterStone); // stone evolution
An overloaded method have different signatures. Here signature means parameters or their sequence. Return type of a method is not included in method signature. At compile time, compiler determines which method should be called depending on the method signature. Hence this is known as Compile time Polymorphism. There are reasons why things are the way they are, like why 39
return types are not included in method signature. I would love to discuss that but I am low on caffeine and it would be a great exercise for you to go and look it up on internet. In the beginning, I said that overloading does not need inheritance, but what if there is inheritance? Let’s say for arguments sake, that all pokemons can naturally evolve. We know that’s not true, but bear with me for a while. Since all pokemons can evolve, let’s put the natural evolution code in Pokemon class. class Pokemon{ private String nickName, type; private int HP,CP; private float height, weight; // All setters and getters public void comeBack(){ } pubic void iChooseYou(){ } pubic void evolve(){ // Natural evolution } }
Now in Eevee class, no need to write the code for natural evolution as it inherits the method from Pokemon class. class Eevee extends Pokemon{ public void evolve(Stone stone){ //evolution by stone } }
40
Even in this case, what we have is method overloading. Method evolve() in Pokemon class is overloaded by method evolve(Stone stone) in Eevee Class. So the following code is still valid: Eevee vee=new Eevee(); vee.evolve(); // natural evolution vee.evolve(waterStone); // stone evolution
This wraps up method overloading.
Constructor Overloading Let’s say we created our pikachu object: Pikachu pika = new Pikachu();
Now we want to set the fields: pika.setHP(10); pika.setType("Electric"); pika.setHeight(3.2);
And so on. Imagine, we need to create 10 pikachu objects and set values for every field. Number of fields that we have defined so far are - 6. So total number of lines we need to write to achieve this are: 6*10 = 600. Coding this way is a sureshot one way ticket to getting kicked out of your company. Constructors to your rescue. Constructors are the piece of code that are responsible to create an object on the heap and assign values to instance variable. They are very similar to a method in a class with 2 specifications 1. There is absolutely no return type - not even void. 41
2. The name of the constructor is same as the class name. Whenever obj=new Pikachu(); is executed, a Pikachu's constructor is called. They can be default or parameterized. (Discussed ahead) But wait, we didn't write a constructor for any of the classes before yet we were able to create their objects. This is because, if there is no (almost) constructor in the class, compiler adds one on its own. So for our Pikachu class, the compiler added constructor would be: class Pikachu extends Pokemon{ Pikachu(){ // default Constructor } pubic void thunderbolt(){ } }
Default constructors sets the instance variables to their default values. So any int field will be 0, String will be null and so on. A parameterized constructor is one which takes values in the parameters and assigns them to the instance variables. class Pikachu extends Pokemon{ Pikachu( int hp,int cp, String nickname,String type, float height,float weight){ setHP(hp); setCP(cp); setNickName(nickname); setType(type); setHeight(height); setWeight(weight); } pubic void thunderbolt(){ 42
} }
Since we have already implemented setters (encapsulation, remember?), let’s just use those to set the values. So far so good. Now we can create a Pikachu object as: Pikachu pika=new Pikachu(10,15,"Pika","Electric",3.2,4.1);
Need another object? Pikachu pika1=new Pikachu(12,10,"Pika1","Electric",3.8,4.5);
If you noticed, this takes care of our 600 lines code problem. No need to explicitly call setters anymore. Now you rock in your job. But what if you ended up doing something like thisPikachu pika2=new Pikachu(); // Compiler cries like an irritated baby
If we only have parameterized constructor in the class, this line can give you nightmares. What happened to compiler adding default constructor? You see, compiler adds default constructor if and only if there is no other constructor defined. Since we have already defined a parametrized constructor, compiler won’t add a default one and the above line of code will fail. In most cases, this is a required behavior as we don’t want anyone to create new Pikachu object without specifying the values for the fields, but if we do want to allow such initialization, for whatever reason, simply add a default constructor. So our Pikachu class becomes: class Pikachu extends Pokemon{ Pikachu(){ } Pikachu( int hp,int cp, String nickname,String type, float height,float weight){ // parameterized constructor. 43
setHP(hp); setCP(cp); setNickName(nickname); setType(type); setHeight(height); setWeight(weight); } pubic void thunderbolt(){ } }
And now you can sleep peacefully. This is called as constructor overloading.
Casting A couple of pages back, we looked at this piece of code – Pikachu pika=new Pikachu(); Pokemon poke=pika; poke.thunderbolt(); // not going to work
And quoted – ‘Since Pokemon class does not contain thunderbolt() method, compiler won’t let you compile the above code.’ But hey, poke is definitely referring to object of Pikachu, so the object must be capable of executing thunderbolt() method. The compile time check is preventing us from executing - poke.thunderbolt(); So, we cast the object. There are two types of casting – Up - Casting
An object is up-casted when it is assigned to the reference type of its class’s parent. Pikachu pika=new Pikachu(); Pokemon poke=pika; 44
Here, object pika is assigned to Pokemon reference type. Remember, Pokemon class is a parent of Pikachu class. This casting is done implicitly and thus requires no additional code. Plain and simple. However, Down – Casting is more fun. Down – Casting
Down casting will help us solve the problem we faced while executing the code - poke.thunderbolt(); And lucky for you, we have already looked at this one in Inheritance chapter. So just to re-cap - we assign an object with a reference type of parent class to its respective object type. Except, this has to be done explicitly. Pikachu pika=(Pikachu)poke; pika.thunderbolt();
Or if you are being really lazy – ((Pikachu)poke).thunderbolt();
Alright, we will stop with polymorphism. If you have somehow understood till here, next part will be a walk in a park.
45
ABSTRACTION Abstract Classes For a while now, we have been slowly creating a class design while learning the OOP concepts. Let’s take a look at what we have done so far.
Fig 5.1 But there is a problem with this design. Bulbasaur bulbasaur=new Bulbasaur(); Squirtle squirtle =new Squirtle(); Pikachu pikachu =new Pikachu();
This code makes sense. We have few pokemons – Bulbasaur, Squirtle and pikachu. But what about this code? Pokemon pokemon = new Pokemon();
Though valid, this code doesn’t make any sense as there is no Pokemon called a Pokemon. We shouldn’t be able to have an object of type Pokemon because, hey, such pokemon cannot exist. So we mark the class as Abstract class. Abstract classes cannot be instantiated and are only useful as parent classes in inheritance. Seems like the kind of thing we want. abstract class Pokemon{ private String nickName, type; 46
private int HP,CP; private float height, weight; // All setters and getters public void comeBack(){ } pubic void iChooseYou(){ } }
The other non-abstract classes which inherit from this class are called as Concrete classes. So all those 151 pokemon classes that you spent a night writing, are concrete classes. Thanks to making your Pokemon class abstract, no other developer, especially Bob, can instantiate it. But reference type of Pokemon can still be used to point to the objects of its child type. Pokemon pokemon = new Pokemon(); // Not valid Pokemon squirtle = new Squirtle(); // works just fine.
Back when we were learning method overloading, and added evolve method in Pokemon Class, it was probably not the best thing to do, since all pokemons don’t evolve. But guess what, many of them do evolve and writing the evolve() method in each of those evolving pokemon class is a tad bit expensive, time consuming, redundant and literally boring. So we create a new class – abstract class EvolvingPokemon extends Pokemon{ public void evolve(){ } }
And make all those evolving pokemon classes extend EvolvingPokemon class instead of Pokemon class. Since EvolvingPokemon is extending from Pokemon class, all fields and methods of Pokemon class are part of EvolvingPokemon class and will also be part of its child classes. class Eevee extends EvolvingPokemon { public void evolve(){ } } 47
class Pikachu extends EvolvingPokemon { public void evolve(){ } } class Onix extends Pokemon { // no evolve method }
Right now, our class design would be –
Fig 5.2 Pokemon and EvolvingPokemon are abstract classes. We can write an implementation of evolve method in EvolvingPokemon class and it would be a default behavior for each pokemon that extends this class. But what if, we want to force all classes to write their own implementation of evolve method? We can make the method abstract. abstract class EvolvingPokemon extends Pokemon { public abstract void evolve(); }
An abstract method does not have any implementation. And remember, any class that has an abstract method, must be declared abstract as well. i.e. only abstract classes can have abstract methods. 48
Also, only a concrete class has to implement all abstract methods. An abstract class that inherits from other abstract class, like EvolvingPokemon inheriting from Pokemon, need not implement the abstract methods in Pokemon class.
Interfaces Spoiler alert – a bit of theory ahead. Interfaces are abstract classes on steroids (or marijuana). Remember we could define data members and method implementations for non-abstract methods in abstract classes? The only thing you can do with interface is define abstract methods and constants. All methods in interface are implicitly public. So why do we need interfaces? They are basically a workaround for a multiple inheritance problem. But here’s a catch. An interface is nothing more than a contract – a contract that says, any class implementing the interface, must implement all the methods defined in the interface. Similar to abstract methods in abstract classes. Let’s say we want to enforce the following conditions on all Pokemons. All water-type pokemons should have splash attack, all fire-type should have ember, electric-type should have thunderbolt and so on. We can create type interfaces and make pokemons implement their respective types. interface WaterType { public void splash(); } interface FireType { public void ember(); } interface ElectricType { public void thunderbolt(); } class Squirtle extends EvolvingPokemon implements WaterType{ 49
public void evolve(){ // from EvolvingPokemon class } public void splash(){ // from interface } } class Charizard extends Pokemon implements FireType{ public void ember(){ // from interface } }
Fig 5.3 What if a pokemon has more than one type? If type were classes, we won’t be able to inherit from multiple type classes, but we can implement multiple interfaces. interface FlyingType { public void wingAttack(); } interface PoisonType { 50
public void sting(); } class Zobat extends EvolvingPokemon implements FlyingType, PoisonType { public void wingAttack (){ // from Flyingtype interface } public void sting (){ // from PoisonType interface } }
So that’s how we can deal with multiple inheritance. Though technically, interfaces cannot be considered as inheritance since all they do is enforce a contract and not does not provide the implementing class with any implemented methods or data members. Also, interfaces can inherit from other interfaces – interface GenerationOneTypes { } interface PoisonType extends GenerationOneTypes { public void sting(); }
Just like inheritance, classes implementing interfaces also are in a IS-A relationship. So, we can still use instanceof operator and all other features of inheritance are supported. For e.g. we can use a reference type of interface to hold a Pokemon type object. FlyingType pokemon=new Pidgey(); pokemon.wingAttack(); // works pokemon.evolve(); // cannot find method
51
And we are done with Abstraction, though it was a bit hastily. There are few more topics that can be discussed in OOP such as Object Composition and cohesion-coupling, but I’ll stop troubling you here.
52
