Object Oriented Programming OOP, is the way almost all programming is done, in almost all languages. It hasn’t been this way forever and there are some exceptions but if we are serious about building games for any platform we need an introduction to get us started. OOP also holds the key to organizing and managing our code as it becomes more complex.
[widgets_on_pages id=”udemy_advert_java_1″][widgets_on_pages id=”udemy_code_details”]

OOP is a way of programming that involves breaking our requirements down into chunks that are more manageable than the whole. Each chunk is self-contained yet potentially reusable by other programs while working together as a whole with the other chunks. These chunks of code are called objects. When we plan 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. However, OOP is more than this. It is also a methodology that defines best practices like the following:

1. Encapsulation: This means keeping the internal workings of your code safe from interference from the programs that use it. 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, as long as the exposed parts are still accessed in the same way.
2. Inheritance: Just like it sounds, inheritance means we can harness all the features and benefits of other peoples’ classes, including encapsulation and polymorphism while refining their code specifically to our situation. We will do this in every single game project we make with both our own classes and the classes provided by Java or Android.
3. Polymorphism: This allows us to write code that is less dependent on the types we are trying to manipulate, making our code clearer and more efficient. Some examples later in our game projects and in the final tutorial of this series will make things a bit clearer.

Java was designed from the start with all of this OOP stuff in mind, so we can’t escape it. However, this is a good thing because we learn to work with it from the very start.

We will see how to use some classes in the remaining tutorials in this series and we will use loads of other people’s classes when we make our games- it is really easy! However, we also need to make our own classes (spaceships, aliens etc) so for the rest of this tutorial, we will concentrate on how we do that.

Building our own classes

A class is a bunch of code that can contain methods, variables, loops and any Java code we have seen. A class is often part of a package of classes that can interact and work with each other. Usually, although not always, each new class will be defined in its own code file with the same name as the class.

Once we have written a class we can use it to make as many objects from it as we need. 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. Let’s take a look.

public class Tank {

	int armour;
	String tankType;

	void shootEnemy(){

		// bang bang

	}

}

Above is a class implementation for a class called Tank. Within the Tank class are two variables, a int variable called armor and a String variable called tankType. There is also a method called shootEnemy. The method has no parameters and a void return type but class methods can be of any shape or size that we discussed in the tutorial Organizing our code with methods.

Remember this is just a class, not an object. It is a blueprint for a tank, not an actual tank. This is how we make an object of type Tank from our Tank class.

Tank myTank = new Tank();

In the first part of the code, Tank myTank declares a new object variable of the type Tank called myTank and the last part of the code new Tank() creates an actual Tank object. And of course, the assignment operator = in the middle of the two parts assigns the result of the second part to that of the first. Just like regular variables.

This is how we would assign to and use the variables inside the Tank class. Variables which are part of a class and not contained inside a method are called members.

myTank.armour = 100;
myTank.tankType = "heavy";

// Notice that we use the object name myTank.
// Not the class name Tank.
// We didn't do this:
// Tank.armour = 100; ERROR!

Above, the dot operator “ ." is used to access the variables of the class. This is also how we use the method; by using the object’s name followed by the dot operator.

myTank.shootEnemy();

We can make as many Tank objects as we like.

Tank myTank2 = new Tank();
myTank2.armour = 25;
myTank2.tankType = "recon";
myTank2.shootEnemy();

// Add as many tanks as you like

It is important to realize that myTank2 is a totally separate object with its very own variables.
[widgets_on_pages id=”udemy_advert_java_3″][widgets_on_pages id=”udemy_code_details”]

Access modifiers

If you were wondering what that public keyword was when we defined our Tank class all will be made clear now. All of our class variables, methods and the classes themselves can be given different access modifiers. We use access modifiers to specify which other classes can access different parts (variables, methods, classes) of our code. This topic on its own is a fairly enormous one but we don’t have to master it to start making games. When we make and use classes during our game projects I will point out when and why we use a particular access modifier.

The two main access modifiers are public and private. Just know that public methods and variables are almost completely accessible and private are generally hidden within the class itself. This allows us to write code that uses variables that can only be manipulated by the code within the class itself. For example, we wouldn’t want a hypothetical Donkey class altering our tanks armour!

Inner classes or regular classes?

I mentioned that classes are ‘defined in its own code file with the same name as the class’. Everything we have discussed regarding classes can be applied to two different types of class. Inner classes or regular classes. Inner classes are defined within the same code that the objects are created in. Regular classes are defined within a separate code file. There are advantages to both types of class, partly about access to variables and we will see both types in action in our first real game.

I didn’t really understand all of that

It doesn’t really matter. As long as you understand that we can design a class which acts like a coded blueprint and that we can create objects from that blueprint that actually use that code then you know enough to proceed. I will fully explain what is happening when we design some classes and create objects from them.

We are really close to being able to start our first game just a few more short tutorials. Let’s look at handling game data with Java arrays.