Hiding Data within Object-Oriented Programming

Introduction

This is the seventh installment in a series of articles about fundamental object-oriented (OO) concepts. The material presented in these articles is based on material from the second edition of my book, The Object-Oriented Thought Process, 2^nd edition. The Object-Oriented Thought Process is intended for anyone who needs to understand the basic object-oriented concepts before jumping into the code. Click here to start at the beginning of the series.

Now that we have covered the conceptual basics of classes and objects, we can start to explore specific concepts in more detail. Remember that there are three criteria that are applied to object-oriented languages: They have to implement encapsulation, inheritance, and polymorphism. Of course, these are not the only important terms, but they are a great place to start a discussion.

In the previous article, this article, and several of the ones that follow, we will focus on a single concept and explore how it fits in to the object-oriented model. We will also begin to get much more involved with code. In keeping with the code examples used in the previous articles, Java will be the language used to implement the concepts in code. One of the reasons that I like to use Java is because you can download the Java compiler for personal use at the Sun Microsystems Web site http://java.sun.com/. You can download the J2SE 1.4.2 SDK (software development kit) to compile and execute these applications and will provide the code listings for all examples in this article. I have the SDK 1.4.0 loaded on my machine. I will provide figures and the output for these examples. See the previous article in this series for detailed descriptions for compiling and running all the code examples in this series.

Checking Account Example

Recall that in the previous article, we created a class diagram that is represented in the following UML diagram; see Figure 1.

Figure 1: UML Diagram for Checking Account Class

This class is designed to illustrate the concept of encapsulation. This class encapsulates both the data (attributes) and methods (behaviors). Encapsulation is a fundamental concept of object-oriented design—all objects contain both attributes and behavior. The UML class diagram is composed of only three parts: the class name, the attributes, and the behaviors. This class diagram maps directly to the code in Listing 1.

class CheckingAccount {
   private double balance = 0;
   public void setBalance(double bal) {
      balance = bal;
   };
   public double getBalance(){
      return balance;
   };
}

Listing 1: CheckingAccount.java

This direct mapping from class diagram to code (and back) is another important issue when designing classes. This mapping not only helps with the design of the class, but also with the maintenance of the class. Multiple class diagrams are used to design an object-oriented system and make up what is termed an object model. Object models will be discussed at length in later articles.

Once a system is complete, the documentation pertaining to the design is obviously very important. The deployment of a new application marks the beginning of the maintenance phase, which will continue for the lifetime of the application and contain many, many bug fixes, updates, and enhancements to the system. While the object-model is a great design tool, it is also a great maintenance tool.

However, as with all documentation, an object model that is not updated as the application changes is at best useless, and at worst misleading. Anyone who has used flowcharts knows exactly what the problem is. For example, consider an application that is deployed with flow charts included in the final documentation. If a bug is identified and fixed in the code, unless the change in logic is retrofitted to the flow chart, the flow chart is out of date and does not represent the current application. In the future, when another programmer, or perhaps even the original programmer, revisits the documentation, it can be misleading. This may lead to a major problem. The same problem can occur when classes change and the class diagram is not updated properly to reflect the changes.

Why have we taken this interlude about updating documentation at this point? Because there now are tools to manage much of the documentation process and I believe that anyone wanting to learn object-oriented design must integrate the knowledge of these tools into their thought process as early as possible. In short, the process of creating class diagrams and mapping them directly to code (and back) is tracked, and somewhat controlled, by software tools. In future articles, we will get into much more detail about the tools themselves. Right now, just be aware that the class diagrams and the code are tightly coupled.

Note: Some of the products that can help with the process are Rational Rose, owned by IBM and Visio, owned by Microsoft.

Data Hiding

Returning to the actual CheckingAccount example, we can see that while the class contains both attributes and behavior, not all of the class is accessible to other class. For example, consider again the balance attribute. Note that balance is defined as private.

private double balance = 0;

We proved in the last article that attempting to access this attribute directly from an application would produce an error. The application that produces this error is shown in Listing 2.

class Encapsulation {

   public static void main(String args[]) {
      System.out.println("Starting myEncapsulation...");
      CheckingAccount myAccount = new   CheckingAccount();
      myAccount.balance = 40.00;
      System.out.println("Balance = " + myAccount.getBalance());
   }

}

Listing 2: Encapsulation.java

The offending line is the where this main application attempts to set balance directly.

myAccount.balance = 40.00;

This line violates the rule of data hiding. As we saw in last month's article, the compiler does not allow this; however, it fails to set balance to 40 only because the access was declared as private. It is interesting to note that the Java language, just as C++, C#, and other languages, allows for the attribute to be declared as public. In this case, the main application would indeed be allowed to directly set the value of balance. This then would break the object-oriented concept of data hiding and would not be considered a proper object-oriented design.

This is one area where the importance of the design comes in. If you abide by the rule that all attributes are private, all attributes of an object are hidden, thus the term data hiding. This is so important because the compiler now can enforce the data hiding rule. If you declare all of a class's attributes as private, a rogue developer cannot directly access the attributes from an application. Basically, you get this protection checking for free.

Whereas the class's attributes are hidden, the methods in this example are designated as public.

public void setBalance(double bal) {
   balance = bal;
};
public double getBalance(){
   return balance;

};

Page 1 of 3