In this chapter, we will discover that in Java, classes are fundamental to everything. We have already talked about reusing other people's code, specifically the Android code, but in this chapter, we will really get to grips with how this works and learn about Object-Oriented Programming as well as how to use it. Here is what is coming up in this chapter.
- Introduction to Object-Oriented Programming including encapsulation, inheritance, and polymorphism
- Write and use our first, very own class
- An explanation about encapsulation and how it is our friend
- Inheritance- a first look and how to take advantage
- An introduction to polymorphism
- Static classes
- Abstract classes and interfaces
- Start the next project- Pong
Let's get started.
I am not going to throw the whole OOP book at you in one go. We will return to and expand upon our OOP knowledge as the book progresses and the games get more advanced.
Before we get to what exactly OOP is, a quick warning.
If you try to memorize this chapter you will have to make a lot of room in your brain and you will probably forget something important in its place, like going to work or thanking the author for telling you not to try and memorize this stuff.
Going back to the car analogy from Chapter 1, Java, Android and Game Development, intimate knowledge of a cars mechanical systems will not make you a great driver. Understanding the options and possibilities of their interfaces (steering wheel, engine performance, breaks etc.), then practicing and testing will serve you much better. A good goal by the end of this chapter will be to try and just-about get it.
We already know that Java is an OOP language. An OOP language needs us to program in a certain way. We have already been doing so we just need to find out a little bit more.
OOP is a way of programming that involves breaking our requirements down into smaller parts that are more manageable than the whole.
Each chunk is self-contained yet potentially reusable by other parts of our code and even by other games and programs while working together as a whole with the other chunks.
These parts or chunks are what we have been referring to as objects. When we plan/code an object, we do so with a class. A class can be thought of as the blueprint of an object.
We implement an object of a class. This is called an instance of a class. Think about a house blueprint. You can't live in it, but you can build a house from it, you build an instance of it. Often when we design classes for games or any other type of program we write them to represent real-world things or tangible concepts from our game.
However, OOP is more than this. It is also a way of doing things, a methodology that defines best practices.
The three core principles of OOP are encapsulation, polymorphism, and inheritance. This might sound complex but if you take a step at a time is reasonably straightforward.
Encapsulation: This means keeping the internal workings of your code safe from unwanted control by the code that uses it, by allowing only the variables and methods you choose, to be accessed. This means your code can always be updated, extended or improved without affecting the programs that use it, provided the exposed parts are still accessed in the same way.
Furthermore, it helps us avoid bugs by limiting which code could be causing buggy behavior. For example, if you write an Invader class and the invader flies in upside down and falls on its back, if you used encapsulation properly then the bug must be in the Invader class, not the game engine.
Think back to this line of code from chapter 1.
locationManager.getLastKnownLocation(LocationManager.GPS_PROVIDER)
With good encapsulation, it doesn't matter if the Satellite company or the Android API team need to update the way their code works. Provided the getLastKnownLocation method signature remains the same we don't have to worry about what goes on inside.
Our code written before the update will still work after the update. If the manufacturers of a car get rid of the wheels and make it an electrically powered hover car; provided it still has a steering wheel, accelerator, and brake pedal, driving it should not be a challenge.
When we use the classes of the Android API we are doing so in the way the Android developers designed their classes to allow us to. When we write classes, we will design them to use encapsulation and be used in the way we decide.
Just like it sounds, inheritance means we can harness all the features and benefits of other peoples' classes, including the encapsulation and polymorphism, while further refining their code specifically to our situation. We have done this already, every time we used the extends keyword.
public class SubHunter extends Activity {The Activity class provided the Sub Hunter game with features like:
- Communication with the operating system
- The
setContentViewmethod to draw our game to the screen - Access to the
onTouchEventmethod which allowed us to detect the player's input - And more…
We got all this benefit without seeing a single line of code from the Activity class. We need to learn how to use these classes and not worry too much about the code that implements them.
Polymorphism allows us to write code that is less dependent on the types we are trying to manipulate, like Invaders, Bullets, and Platforms and allows us to deal with more generic things like perhaps GameObjects, making our code clearer and more efficient.
Polymorphism means different forms. If the objects that we code can be more than one type of thing, then we can take advantage of this. Some working examples later in the chapter will help but we will really get to grips with polymorphism as a concept in Chapter 18, Introduction to Design Patterns and much more!.
When written properly, all this OOP allows you to add new features without worrying much about how they interact with existing features. When you do have to change a class, its self-contained (encapsulated) nature means less or perhaps even zero consequences for other parts of the program.
OOP allows you to write games with huge, fascinating, explorable worlds and break that world into manageable parts and types of "thing". By thing, you can probably guess I mean class.
You can create multiple, similar, yet different versions of a class without starting the class from scratch by using inheritance; and you can still use the methods intended for the original type of object with your new object because of polymorphism.
Makes sense really. And Java was designed from the start with all of this in mind. For this reason, we are forced into using all this OOP but, this is a definitely a good thing. Let's have a quick class recap.
A class is a bunch of code that can contain methods, variables, loops, and all the other Java syntax we have learned so far. We created a class in the first seven chapters. It was called SubHunter and it inherited the features of Activity provided by Android. Next is the line of code which achieved this. In it, you can see that the extends keyword creates this relationship.
public class SubHunter extends Activity {That's how we got access to features getWindowManager, getDefaultDisplay, and the onTouchEvent methods.
A class is part of a Java package and most packages will normally have multiple classes. Our SubHunter class was part of a package that we defined when we created the project. Usually, although not always, each new class will be defined in its own .java code file with the same name as the class; as with SubHunter.
Once we have written a class we can use it to make as many objects from it as we want. We did not do this with SubHunter but every Android programmer in the world (including us) has certainly made objects by extending Activity. And we will make objects from our own classes in every remaining project in this book.
Remember, the class is the blueprint and we make objects based on the blueprint. The house isn't the blueprint just as the object isn't the class; it is an object made from the class. An object is a reference type variable, just like a String and later in Chapter 14, The Stack, The Heap and The Garbage Collector, we will discover exactly what being a reference variable means. For now, let's look at some real code that creates a class.