Exploring Encapsulation

Compiling and Executing These Examples

Before we proceed any further, let's define how the code listings in this article are compiled and executed. There are many different options that may be used to accomplish this task. As noted previously, we will be using the J2SE 1.4.2 SDK to compile and execute these applications. Using this Java SDK has a number of advantages. First, it is readily available for personal use at the Sun Microsystems Web site. Second, it is easy to move this code from one platform to another. Third, using the SDK provides experience in using a console-based platform. Some people may not consider the third point as an advantage. I believe that it is very helpful when learning a language and/or a concept to use a language at its basic syntax level. While many may balk at using a DOS or Unix shell, gaining experience with a console application is a definite advantage even with the state-of-the-art of current graphical use interfaces.

Download and install the SDK on your machine. Accept the default location for installation directories on your C: drive.

Now, let's compile and run this application on a Windows platform (the same techniques will work equally well on a Unix platform). For ease of use, you may want to use the same names that I use to create my directories. To begin, create a directory called example. This directory will contain the files for this example. In this directory, place the files from Listing 1 and Listing 2. These files must have the same name as the name of the classes they represent.

I like to use the batch files because I often have multiple versions of the SDK on my machine for testing proposes. Using these batch files ensures that I am using the specific version of the SDK that I want. The .classpath option ensures that the files used in compilation are from the current directory, in this case the directory called example.

To execute the application, I use a similar batch file that I call go.bat. Listing 4 shows what this file looks like.

Data Hiding

Perhaps the most important object-oriented concept is that of data hiding. Remember from earlier columns that data hiding means access to all of an object's attributes is tightly controlled. This is accomplished by making all the attributes private. In the CheckingAccount class, we only have a single attribute:

private double balance = 0;

This attribute is hidden from all other objects because of the private designation. To prove this, let's try to access the balance attribute directly from the myAccount object. Consider the following code:

The complier realizes that the programmer designed the Checking Account class with balance as private. Thus, the compiler enforces this concept—balance is strictly off-limits to any object other than its own instance of myAccount.

You may ask, "What happens if balance is declared as public?"

public double balance = 0;

In this case, the code in Listing 5 executes cleanly. Try making this change to the code. Then, compile and execute it. It will work, but this violates the concept of data hiding. And this is a very important point. Data hiding, as with many other object-oriented concepts, is a design decision. In short, if you design the system with your attributes as private, the compiler can help you with enforcing data hiding. However, if you design your classes with public attributes, you have not designed your application in an object-oriented manner.