November 1, 2020
Hot Topics:

Protecting Data through Object Oriented Programming

  • By Matt Weisfeld
  • Send Email »
  • More Articles »





This is the eight 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, 2nd 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.


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 previous articles in this series for detailed descriptions for compiling and running all the code examples in this series.


Checking Account Example


In this column we will focus on how to protect data from either unintentional mistakes or intentional malicious behavior. To accomplish this we will continue in our development of an ATM example. In the previous column, we developed a simple checking account example. Let's do a quick review of this class before we proceed.


Figure 1 shows the UML class diagram that corresponds to our latest design.


Figure 1: UML Diagram for Checking Account Class


Listing 1 displays the code that corresponds directly to the class in Figure 1.


class CheckingAccount {
   private double balance = 0;
   private void setBalance(double bal) {
      balance = bal;
   public double getBalance(){
      return balance;
   public void deposit(double dep){
        setBalance(balance + dep);
   public void withdrawal(double with){
        setBalance(balance - with);

Listing 1: CheckingAccount.java

In effect we now have the following components to our CheckingAccount class.


  1. The private attributes
    1. balance
  2. The private implementation
    1. setBalance()
  3. The public interfaces
    1. deposit()
    2. withdrawal()
    3. getBalance()


Now that we have developed the CheckingAccount class - let's use the class in an actual application.


Creating an Application


It is important to realize that an application must be created before utilizing a class. In Java, an application is defined by a method called main(). Technically, everything in Java is considered a class (except for some primitives like int and float). To get a application up and running we will create 2 Java files and each of these files will contain a class. These 2 files will contain the CheckingAccount class and the main() application class (I put only one class per each file). We have already seen the CheckingAccount class, the barebones main() application class is contained in listing 2.


class TestCheckingAccount {
    public static void main(String args[]) {


Listing 2: TestCheckingAccount.java

The line of code that contains main() defines this as an application - basically the entry point to the applications. Notice that the file names must match the class names. Thus, the class TestCheckingAccount is contained in a file called TestCheckingAccount.java. At this point the TestCheckingAccount application will execute but it doesn't do anything. What we want it to do is utilize the CheckingAccount class that we have created. We can instantiate a CheckingAccount object in our application by adding the code in Listing 3.


class TestCheckingAccount {
    public static void main(String args[]) {

        CheckingAccount myAccount = new CheckingAccount();



Listing 3: TestCheckingAccount.java

When this code is executed an actual CheckingAccount object, called myAccount,  is created; however, we still have yet to do anything with it. To illustrate what we can do with the newly created object, let's examine what the value of the current balance is. Since we initialized it to 0, we should expect that to be the value.

This is a great opportunity to explore how data in an object is actually protected. Consider the possibility that a rogue employee decides to write an application which will inspect the balances of all checking accounts. At first, this seems like a very simple problem to solve - simply write code that inspects the attribute balance directly. The code may look something like Listing 4.

class TestCheckingAccount {
    public static void main(String args[]) {

        CheckingAccount myAccount = new CheckingAccount();

        System.out.println("balance = " + myAccount.balance);


Listing 4: TestCheckingAccount.java

The logic of this code dictates that the balance will be printed when the println() is executed.

        System.out.println("balance = " + myAccount.balance);

This line attempts to access the attribute balance of the myAccount object. In a proper object-oriented design, it is unacceptable for an application to have uncontrolled access to an attribute. This is a security issue. You never want uncontrolled access to data in an object. In fact, this data protection is already designed into the CheckingAccount class. Remember that the balance attribute was declared as private. Thus, when we try to compile the code in Listing 4 the compiler acts as a security guard and will not let the code compile. The compiler produces the following error:

TestCheckingAccount\TestCheckingAccount.java:6: balance has private access in CheckingAccount
System.out.println("balance = " + myAccount.balance);

Pay special attention to the word private. Since we (properly) declared balance as private, the attribute is protected from uncontrolled access. You may be wondering what the term uncontrolled access actually means since we have used it several times already.

Page 1 of 2

This article was originally published on December 30, 2004

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date