3.7. Apply encapsulation principles to a class

[6.5] Apply encapsulation principles to a class

As the heading of this section suggests, we’ll apply the encapsulation principle to a class. A well-encapsulated object doesn’t expose its internal parts to the outside world. It defines a set of methods that enables the users of the class to interact with it.

As an example from the real world, you can compare a bank to a well-encapsulated class. A bank doesn’t expose its internal parts—for example, its vaults and bank accounts—to the outside world, just as a well-encapsulated class in Java shouldn’t expose the variables that it uses to store the state of an object outside that object. The way a bank defines a set of procedures (such as key access to vaults and verification before money withdrawals) to protect its internal parts is much like the way a well-encapsulated class defines methods to access its variables.

3.7.1. Need for encapsulation

The private members of a class—its variables and methods—are used to hide information about a class. Why would you need to hide class information? Compare a class with yourself. Do you want everyone else to know about all of your weaknesses? Do you want everyone else to be able to control your mind? The same applies to a class that you define in Java. A class may need a number of variables and methods to store an object’s state and define its behavior. But it wouldn’t like all the other classes to know about it. Here’s a quick list of reasons to encapsulate the state of a Java object:

• To prevent an external object from performing dangerous operations
• To hide implementation details, so that the implementation can change a second time without impacting other objects
• To minimize the chance of coupling

Let’s work with an example. Here’s the definition of the class Phone:

Because the variable weight isn’t defined as a private member, any other class (in the same package) can access it and write any value to it, as follows:

3.7.2. Apply encapsulation

In the previous section, you might have noticed that the object fields of a class that isn’t well encapsulated are exposed outside the class. This approach enables the users of the class to assign arbitrary values to the object fields.

Should this be allowed? For example, going back to the example of the Phone class discussed in section 3.7.1, how can the weight of a phone be a negative value?

Let’s resolve this issue by defining the variable weight as a private variable in the class Phone, as follows (irrelevant changes have been omitted):

class Phone {
    private double weight;
}

But now this variable won’t be accessible in the class Home. Let’s define methods using this variable, which can be accessible outside the class Phone (changes in bold):

The method setWeight doesn’t assign the value passed to it as a method parameter to the instance variable weight if it’s a negative value or a value greater than 1,000. This behavior is known as exposing object functionality using public methods.

Let’s see how this method is used to assign a value to the variable weight in the class Home:

Note that when the class Home tries to set the value of the variable to -12.23 or 77712.23 (out-of-range values), those values aren’t assigned to the Phone’s private variable weight. It accepts the value 12.23, which is within the defined range.

On the OCA Java SE 8 Programmer I exam, you may also find the term information hiding. Encapsulation is the concept of defining variables and the methods together in a class. Information hiding originated from the application and purpose of the concept of encapsulation. These terms are also used interchangeably.

Exam Tip

The terms encapsulation and information hiding are used interchangeably. By exposing object functionality only through methods, you can prevent your private variables from being assigned any values that don’t fit your requirements. One of the best ways to create a well-encapsulated class is to define its instance variables as private variables and allow access to these variables using public methods.

The next Twist in the Tale exercise has a little hidden trick about determining a correctly encapsulated class. Let’s see if you can find it (answer in the appendix).

Twist in the Tale 3.3

Let’s modify the definition of the class Phone that I previously used to demonstrate the encapsulation principle in this section. Given the following definition of class Phone, which of the options, when replacing the code on lines 1–3, makes it a well-encapsulated class?

class Phone {
    public String model;
    double weight;                                   //LINE1
    public void setWeight(double w) {weight = w;}    //LINE2
    public double getWeight() {return weight;}       //LINE3
}

Options:

1. public double weight;
   private void setWeight(double w) { weight = w; }
   private double getWeight() {    return weight; }

2. b

   public double weight;
   void setWeight(double w) { weight = w; }
   double getWeight() {    return weight; }

3. c

   public double weight;
   protected void setWeight(double w) { weight = w; }
   protected double getWeight() {    return weight; }

4. d

   public double weight;
   public void setWeight(double w) { weight = w; }
   public double getWeight() {    return weight; }

5. None of the above

Well-encapsulated classes don’t expose their instance variables outside their class. What happens when the methods of these classes modify the state of the method arguments that are passed to them? Is this acceptable behavior? I’ll discuss what happens in the next section.