GAME DEVELOPMENT TUTORIAL: DAY 1-10: Inheritance, Interface

Welcome to Day 10, Unit 1's penultimate lesson! 

This is the beginning of the end of the Basic Java unit.
With that said, you will still be learning Java throughout the future Units, so keep your minds open and ready to learn!

In this lesson, we will be discussing inheritance and interfaces (not in extensive detail, as they will come up frequently in future Units and it is easiest to understand them as you manipulate them yourself). 

Since this lesson is the culmination of the previous lessons in the Unit, we will be applying much of what we learned previously.

If you need to refresh your memory, refer to the previous lessons!

Let's get started!

Lesson #1-19: Interfaces

If you've ever seen highly functional Java code, you might notice something like this in the class declaration: 

 public class ClassName implements InterfaceName {
   ... //implemented methods
} 

This line of code creates a class named ClassName and declares that it implements the interface named InterfaceName.

Yeah, that's quite a mouthful... so you can think of it this way.

An interface is a collection of abstract (meaning that it's not really used, but it's just there as a reference) methods and constants that define a group. 

If a class implements this interface, then it chooses to take on all the abstract methods and constants.

For example, let's say we have an interface called Human as below: 

 public interface Human {
    
    public void eat();
    public void walk();
    public void pee();

} 

The interface is some thing of a contract. If we create an interface, we are telling people, "Hey, you can be a Human if you do the following..."

Notice that an interface does not have method bodies. Instead, we simply declare what methods we need for something to be "Human", and we leave them blank. Each implementation of Human can choose how they want to approach the eat, walk and pee methods.

Here's an example:
I am implementing Human (that is, accepting its three requirements) in the class King:

 public class King implements Human {
    
    public void eat() {
        System.out.println("The King eats.");
    }
    
    public void walk() {
        System.out.println("The King walks.");
    }
    
    public void pee() {
        System.out.println("The King urinates.");
    }
} 

When class King implements interface Human, the class is basically saying, "I will eat, walk, and pee. Please make me Human."

In other words, King is saying that, first and foremost, he is Human.

When you implement an interface in a Class, you must implement (or finish) everything you have stated in the interface. That means the King cannot remove the pee() method from his Class because he is, after all, only human.

You can add as many Interfaces to King as you want, such as "Male" and "Royalty". Then, you can use the King object in any method that requires a King or Human or Male or Royalty input, such as:

 // You can pass in a King object into this method.
public void doSomething(Human h) {
    // do something
} 

This is called polymorphism. You will see the power of polymorphism throughout this tutorial series.

Lesson #1-20: Inheritance

This is a very similar topic to interfaces.

The key difference is that inheritance deals with two classes, not a class and an interface.
Another key difference is that inheritance uses the keyword "extends" rather than "implements."

So how is "extends" different from "implements?"

Recall that when you implement an interface, you must take all the abstract qualities of the interface and implement it into the Class that is implementing it.

Not so when a class extends another class, which we refer to as a Superclass, and the extending class is called a subclass.

A class is a blueprint for objects, as I have repeated over and over again.
A superclass is a blueprint for other classes.

In inheritance, we take an abstract concept, like Phone, and create a class which will hold all the shared properties of all Phones. Then, we can use this as a blueprint to create more specialized objects, such as the iPhone class or the GalaxyS class.


Let's have a look at an example: 

 // This is the 'generic' superclass

class Phone {
    
    // Phone class variables
    int weight = 10;
    int numProcessingCores = 4;
    int price = 200;
    boolean turnedOn = false;
    
    public void togglePower() {
        // turnedOn is now its opposite (true becomes false, and vice versa)
        turnedOn = !turnedOn;
    }
} 

This superclass holds all the information that all phones should have, such as weight, number of cores, price and etc. Using this superclass, we can create a subclass, which will (this is key) ADD ITS OWN UNIQUE PROPERTIES to the GENERIC properties described in the superclass (meaning that iPhone below will have all the methods and variables in the Phone method and also its own methods and variables): 

 public class iPhone extends Phone {
    
    boolean hasAppleLogo = true;
    String color = "black";
    
    void adjustPrice() {
        if (hasAppleLogo) {
            // Although we did not declare a price variable in this class
            // we have inherited a copy of it from the Phone class.
            price += 4500;
        }
    }
} 

Now the class iPhone will be able to use all the methods and constants defined in the superclass Phone... and add its own methods (like adjustPrice()) 

Now the class iPhone will be able to use all the methods and variables defined in the superclass Phone... and add its own methods (like adjustPrice()) 

Polymorphism also works with inheritance.

Let's say we have a Hammer class:

 public class Hammer {

    public boolean destroy(Phone p) {
        p.turnedOn = false;
        p.price = 0;
        System.out.println("BOOM");
    }
    
} 

Its destroy method can destroy any Phone, and any other Object that extends Phone. Here's how you might do that.

 public class Hammer {

    public boolean destroy(Phone p) {
        p.turnedOn = false;
        p.price = 0;
        System.out.println("BOOM");
    }
    
    public static void main(String[] args) {
        Hammer h = new Hammer();      // Create new hammer object
        Phone phone = new Phone();    // Create new Phone object
        iPhone phone2 = new iPhone(); // Create new iPhone object
        
        h.destroy(phone);  // Destroy Phone object
        h.destroy(phone2); // Destroy iPhone object (POLYMORPHISM!)
    }
    
} 

The destroy method does not have to be static, because we are using an instance of the Hammer class, named h, to call the destroy method. If we didn't want to create a specific Hammer to destroy things, we would make the destroy method static, and call:

Hammer.destroy(...);

Not an extremely long lesson, but this is a very important one. Read through it thoroughly!
One more thing...

If each of you told your friends about this tutorial and asked them to like us on Facebook, it would help us out tremendously. 

Take the time to support Kilobolt!  :D

Go to Day 9: More on Looping

Go to Day 11: Threads and Graphics