August 1, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Exploring Encapsulation

  • June 30, 2004
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

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.

CheckingAccount.java

Encapsulation.java

To compile these classes, I like to create a batch file in DOS I call make.bat. Listing 3 shows what this file looks like.

REM Compile Java FilesC:\j2sdk1.4.0\bin\javac -classpath . CheckingAccount.javaC:\j2sdk1.4.0\bin\javac -classpath . Encapsulation.java

Listing 3: make.bat

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.

REM Run the ApplicationC:\j2sdk1.4.0\bin\java -classpath . Encapsulation

Listing 4: go.bat

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:

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 5: Encapsulation.java (trying to directly access balance)

The following line of code illustrates what we mean by private, hidden data. In this line of code, the application object is trying to directly set balance to 40.00.

myAccount.balance = 40.00;

However, because the attribute is defined as private, the compiler will not allow this. Figure 3 shows how the compiler reacts to compiling the code in Listing 5.



Click here for a larger image.

Figure 3: Output with private balance.

Pay special attention to the error message that the compile provides:

Encapsulation.java:8: balance has private access in CheckingAccountmyAccount.balance = 40.00;

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.





Page 2 of 3



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel