October 23, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Protecting Data through Object Oriented Programming

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

Data Protection

Consider what happens when you use an ATM and you want to inspect your account balance. After you swipe your card, do you have uncontrolled access to your balance at that time? No. You still need to do at least one more thing - enter your PIN. It is only after you enter your PIN that you gain access to you account and start posting transactions. This is what is meant by uncontrolled access. In the vast majority of  business transactions, controlled access to data is vital - even required by law. This is why attributes in an object are accessed via methods and not referenced directly. We have no mechanism to control access to public attributes. However, we can insert code into methods to control access to attributes in objects. Perhaps the most common example would be that of passwords - which are similar to the PIN example.

Consider your email client. What happens when you want to change your password? Are you able to directly change your password? Absolutely not. You must execute a change password routine to accomplish the task. In fact, it is not quite as simple as that. You not only have to execute the change password routine, you must also know your original password. This is an obvious security issue. You don't want to walk away from your computer for a break and then have someone sit down at your machine and directly reset your password. What you do want is for a change password routine to require the original password be entered before the new password is set.

We will explore this password issue later, however; we can now return to the problem of how to inspect the balance. At this point the answer should be obvious. The answer is a method and in this case the getBalance() method. This code is shown in Listing 5.

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

        CheckingAccount myAccount = new CheckingAccount();

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

    }
}

Listing 5: TestCheckingAccount.java

Thus, the way to access (inspect) the balance attribute is through the  method getBalance().

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

When this code executes, the output produced is presented in Figure 2. Here we can see that the initial value of balance is indeed 0.

Figure 2: TestCheckingAccount Application

There is one more level of data protection that was designed into the CheckingAccount class. Consider that our rogue programmer figures out pretty quickly that there is absolutely no way to directly access the balance attribute. If we need to access via a method that is what we will do. There is a method called setBalance() so let's set the balance to $1000. Consider the code in Listing 6.

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

        CheckingAccount myAccount = new CheckingAccount();

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

        myAccount.setBalance(1000);

    }
}

Listing 6: TestCheckingAccount.java

Here the programmer attempts to set the balance through the setBalance() method. However, the compiler will flag this as well because the method was declared as private. Basically , the designers of the CheckingAccount class wanted this method to be used only by objects of this class.

        myAccount.setBalance(1000);
 

This code produces the following compiler error:

TestCheckingAccount\TestCheckingAccount.java:8: setBalance(double) has private access in CheckingAccount
myAccount.setBalance(1000);
 

Thus, while we can say that all attributes should be private, we cannot say that all methods are public. Perhaps most methods will be public; however,  there are appropriate design situations for private methods. In the case of the CheckingAccount class, the only way to change the balance attribute is to either make a deposit or a withdrawal.

In Listing 7 the code is included to make a deposit and then a withdrawal.

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

        CheckingAccount myAccount = new CheckingAccount();

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

        myAccount.deposit(1000);

        myAccount.withdrawal(100);

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

   
    }
}

Listing 7: TestCheckingAccount.java

In Listing 7 we make a deposit of $1000 and then withdrawal $100. This should leave us with a balance of $900. By executing the application we can verify this. Figure 3 shows what happens when we do execute this application.

Figure 3: TestCheckingAccount Application

Note: You may be wondering why our rogue programmer would even know the names of private attributes and methods. The answer is that the programmer would not - or at least should not. If the application environment is properly designed, the application programmer would not have access to the design or the source code of the CheckingAccount class. The programmer's use of the CheckingAccount class would be via class packages (in some ways analogous to libraries). Only the documentation of the public methods would be made available to the programmer. In theory, the programmer would not even know the name of the balance attribute or the setBalance() method. You may not even want to choose common names for these attributes and methods.

Adding a Password

Finally, let's implement a simple password example to demonstrate some of the data protection concepts discussed earlier. This will be a very primitive example, but it illustrates the point.

Listing 8 includes new code in the CheckingAccount class that implements a method to change a password attribute. The password is initially set to a blank.

class CheckingAccount {

    private double balance = 0;
    private String password = " ";

    public void setPassword(String s1, String s2) {
        if (password = = s1) {
            password = s2;
            System.out.println("Password changed");
        } else {
            System.out.println("Bad password");
        }
    };
    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 8: CheckingAccount.java

This is a very simplistic implementation intended to illustrate the concepts. In this code, we call setPassword() with 2 parameters. The first is the old password and the second is the new password. If the old password is incorrect, an error message is printed. If the old password in entered correctly , then the password is changed and a message indicating this is printed.

    public void setPassword(String s1, String s2) {
        if (password = = s1) {
            password = s2;
            System.out.println("Password changed");
        } else {
            System.out.println("Bad password");
        }
    };

This is a good example of how access to an attribute is controlled. And this entire article is all about stressing the importance of controlling access to all attributes. Listing 9 shows the an application that does not use the proper old password.

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

        CheckingAccount myAccount = new CheckingAccount();

        myAccount.setPassword("x", "1234");

    }
}

Listing 9: TestCheckingAccount.java

As we can see when we run the application, the class will not allow the password to be changed if the old password is incorrectly entered. figure 4 shows the output.

Figure 4: TestCheckingAccount Application

Conclusion

In this month's article, we continued our discussion about encapsulation and data hiding. Controlling access to all attributes is one of the most important concepts of object-oriented design. By using methods to control access to attributes we can provide a much higher level of security for your class as well as providing many programming advantages.

Next month we will discuss the importance of putting an object into what is called a safe state. Not only is it important for an object to have the appropriate security, but the object must also be robust.

About the Author

Matt Weisfeld is an Assistant Professor at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a part of the Information Technology department, teaching programming languages such as C++, Java, and C# .NET as well as various Web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management.

The articles in this series are adapted from The Object-Oriented Thought Process 2nd Edition (published by Sams Publishing). Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb's Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.





Page 2 of 2



Comment and Contribute

 


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

 

 


Sitemap | Contact Us

Rocket Fuel