The designer of the class controls what can be seen and manipulated by any program that uses their class. We can add an access modifier before the class keyword, like this:

public class Soldier{
   //Implementation goes here
}

To build on the class visibility controls, we have variable access modifiers. Here is a variable with the private access modifier being declared:

private int myInt;

Also note that all our discussion of variable access modifiers applies to object variables, too. For example, here is an instance of our Soldier class being declared, created, and assigned. As you can see, the access specified in this case is public:

public Soldier mySoldier = new Soldier();

Before you apply a modifier to a variable, you must first consider class visibility. If class a is not visible to class b – say, because class a has default access and class b is in another package – then it doesn't make any difference what access modifiers you use on the variables in class a: class b can't see any of them.

So, it makes sense to show a class to another class when necessary, but only to expose the variables that are needed – not everything.

Here is an explanation of the different variable access modifiers.

We already briefly mentioned in Chapter 9, Java Methods, that methods have access modifiers. This makes sense since methods are the things that our classes can do. We will want to control what users of our class can and can't do.

The general idea here is that some methods will do things internally only and are therefore not needed by users of the class. Some methods will be fundamental to how users of the class use your class.

public useMeEverybody(){
   //do something everyone needs to do here
}

private secretInternalTask(){
   /*
         do something that helps the class function internally
         Perhaps, if it is part of the same class,
         useMeEverybody could use this method...
         On behalf of the classes outside of this class.
         Neat!
   */
}

fairlySecretTask(){
   // allow just the classes in the package
   // Not for external use
}

protected packageTask(){
   // Allow just the classes in the package
   // And you can use me if you extend me too
}

Now we need to consider, if it is a best practice to hide our variables away as private, how would we allow access to them without spoiling our encapsulation. What if an object of the Hospital class wanted access to the health member variable from an object of the Soldier type so that it could increase it? The health variable should be private because we don't want just any piece of code changing it.

To be able to make as many member variables as possible private and yet still allow some kind of limited access to some of them, we use getters and setters. Getters and setters are just methods that get and set variable values.

This is not some special new Java thing that we have to learn. It is just a convention for using what we already know. Let's have a look at getters and setters by using our Soldier and Hospital class example.

In this example, each of our two classes are created in their own file but in the same package. First of all, here is our hypothetical Hospital class:

class Hospital{

   private void healSoldier(Soldier soldierToHeal){
         int health = soldierToHeal.getHealth();
         health = health + 10;
         soldierToHeal.setHealth(health);
   }

}

Our implementation of the Hospital class has just one method, healSoldier. It receives a reference to a Soldier object as a parameter. So, this method will work on whichever Soldier object is passed in: vassily, wellington, rambo, or whoever.

It also has a local health variable, which it uses to temporarily hold and increase the soldier's health. In the same line, it initializes the health variable to the Soldier object's current health. The Soldier object's health is private, so the public getter method, getHealth, is used instead.

Then, health is increased by 10 and the setHealth setter method loads up the new revived health value, back to the Soldier object.

The key here is that although a Hospital object can change a Soldier object's health, it only does so within the bounds of the getter and setter methods. The getter and setter methods can be written to control and check for potentially mistaken – even harmful – values.

Next, let's look at our hypothetical Soldier class with the simplest implementation possible of its getter and setter methods:

public class Soldier{
   
   private int health;

   public int getHealth(){
         return health;
   }

   public void setHealth(int newHealth){

         // Check for stupid values of newHealth
         health = newHealth;
   }
}

We have one instance variable called health, and it is private. Private means that it can only be changed by methods of the Soldier class. We then have a public getHealth method, which returns the value held in the private health int variable. As this method is public, any code with access to an object of the Soldier type can use it.

Next, the setHealth method is implemented. Again, it is public, but this time it takes an int as a parameter and assigns whatever is passed in to the private health variable. In a more life-like example, we would write some more code here to make sure that the value passed in is within the bounds we expect.

Now, we declare, create, and assign to make an object of each of our two new classes and see how our getters and setters work:

Soldier mySoldier = new Soldier();
// mySoldier.health = 100;//Doesn't work, private

// we can use the public setter setHealth() instead
mySoldier.setHealth(100); //That's better

Hospital militaryHospital = new Hospital();

// Oh no mySoldier has been wounded
mySoldier.setHealth(10);

/*        
   Take him to the hospital.
   But my health variable is private
   And Hospital won't be able to access it
   I'm doomed - tell Laura I love her

   No wait- what about my public getters and setters?
   We can use the public getters and setters 
   from another class
*/

militaryHospital.healSoldier(mySoldier);

// mySoldiers private variable health has been increased 
// by 10. I'm feeling much better thanks!

We can see that we can call our public setHealth and getHealth methods directly on our object of the Soldier type. Not only that, we can call the healSoldier method of the Hospital object, passing in a reference to the Soldier object, which too can use the public getters and setters to manipulate the private health variable.

We can see that the private health variable is simply accessible, yet totally within the control of the designer of the Soldier class.

If you want to play around with this example, there is the code for a working app in the code bundle in the Chapter 11 folder called GettersAndSetters. I have added a few lines of code to print to the console. We deliberately covered this the way we did to keep the key parts of the code as clear as possible.

Yet again, our example and the explanation are probably raising more questions. That's good.

By using encapsulation features (such as access control), it is like signing a really important deal about how to use and access a class, its methods, and variables. The contract is not just an agreement about now, but an implied guarantee for the future. We will see that, as we go ahead through this chapter, there are more ways that we refine and strengthen this contract.

With all these private variables and their getters and setters, does it mean that we need a getter and a setter for every private variable? What about a class with lots of variables that need initializing at the start. Think about the following:

mySoldier.name
mysoldier.type
mySoldier.weapon
mySoldier.regiment
...

Some of these variables might need getters and setters, but what if we just want to set things up when the object is first created to make the object function correctly?

Surely, we don't need two methods (a getter and a setter) for each?

Fortunately, this is unnecessary. For solving this potential problem, there is a special method called a constructor. We briefly mentioned the existence of a constructor when we discussed instantiating an object from a class in Chapter 10, Object-Oriented programming. Let's look at constructors once more.

Here, we create an object of the Soldier type and assign it to an object called mySoldier:

Soldier mySoldier = new Soldier();

Nothing new here, but look at the last part of that line of code:

...Soldier();

This looks suspiciously like a method.

All along, we have been calling a special method called a constructor that has been created, behind the scenes, automatically, by the compiler.

However – and this is getting to the point now – as with a method, we can override it, which means we can do useful things to set up our new object before it is used. The following code shows how we could do this:

public Soldier(){
   // Someone is creating a new Soldier object
   
   health = 200;
   // more setup here
}

The constructor has a lot of syntactical similarities to a method. It can, however, only be called with the use of the new keyword, and it is created for us automatically by the compiler – unless we create our own, as in the previous code.

Constructors have the following features:

One more piece of Java syntax that is useful to introduce at this point is the Java this keyword.

The this keyword is used when we want to be explicit about exactly which variables we are referring to. Look at this example constructor, again for a hypothetical variation of the Soldier class:

public class Soldier{

   String name;
   String type;
   int health;

   // This is the constructor
   // It is called when a new instance is created
   public Soldier(String name, String type, int health){

          // Someone is creating a new Soldier object
          
          this.name = name;
          this.type = type;
          this.health = health;

          // more setup here
   }
}

This time, the constructor has a parameter for each of the variables we want to initialize. By using the this keyword, it is clear when we mean the member variable or the parameter.

There are more twists and turns to be learned about variables and this, and they make much more sense when applied to a practical project. In the next app, we will explore all we have learned so far in this chapter and some more new ideas too.

First, let's look at a bit more OOP.

We know quite a lot about classes already. For example, we know how to turn them into objects and use their methods and variables. But something isn't quite right. Since the very start of this book, we have been using two classes more than any other. We have repeatedly used Log and Toast to output to the logcat or the users screen, but have not instantiated them once! How can this be? We never did this:

Log myLog  = new Log();
Toast myToast = new Toast();

We just went ahead and used the classes directly, like this:

Log.i("info","our message here");
Toast.makeText(this, "our message",      
Toast.LENGTH_SHORT).show();

The static methods of classes can be used without first instantiating an object of the class. We can think of this as a static method belonging to the class and all other methods belonging to an object/instance of a class.

And, as you have probably realized by now, Log and Toast both contain static methods. To be clear: Log and Toast contain static methods; they themselves are still classes.

Classes can have both static and regular methods as well, but the regular methods would need to be used in the regular way, via an instance/object of the class.

Let's take another look at Log.i in action:

Log.i("info","our message here");

Here, i is the method being statically accessed, and the method takes two parameters, both of type String.

Next, we can see the makeText static method of the Toast class in use:

Toast.makeText(this, "our message", 
      Toast.LENGTH_SHORT).show();

The makeText method of the Toast class takes three arguments.

First is this, which takes some explaining. We saw when talking about constructors that to explicitly refer to the member variables of the current instance of an object, we can use this.health, this.regiment, and so on.

When we use this as we do in the previous line of code, we are referring to the instance of the class itself. Not the Toast class, but the this in the previous line of code is a reference to the class the method is being used from. In our case, we have used it from MainActivity.

Many things in Android require a reference to an instance of Activity to do its job. We will – fairly regularly throughout this book – pass in this (a reference to the Activity) in order to help a class/object from the Android API do its work. We will also write classes that need this as an argument in one or more of its methods. So, we will see how to handle this when it is passed in as well.

The second argument is, of course, a String.

The third argument is accessing a final variable, LENGTH_SHORT, again via the class name, not an instance of the class. This is achieved if we declare a variable like we do in the following line of code:

public static final int LENGTH_SHORT = 1;

If the variable was declared in a class called MyClass, we could access the variable like this: MyClass.LENGTH_SHORT, and use it like any other variable, but the final keyword makes sure that the value of the variable can never be changed. This type of variable is called a constant.

The static keyword also has another consequence for a variable, especially when it is not a constant (can be changed), and we will see this in action in our next app.

Now, if you look carefully at the very end of the line of code that shows a Toast message to the user, you will see something else new, .show().

This is called chaining, and all we are doing is calling a second method of the Toast class but using just one line of code. It is the show method that actually triggers the message.

We will see some more chaining as we proceed through this book, like in Chapter 14, Android Dialog , when we make pop-up dialogs.

Static methods are often provided in classes that have uses that are so generic that it doesn't make sense to have to create an object of the class. Another really useful class with static methods is Math. This class is actually a part of the Java API, not the Android API.

If you try this out, you will need to import the Math class in the same way that we imported all the other classes we have used.