November 28, 2014
Hot Topics:

Hiding Data within Object-Oriented Programming

  • July 29, 2004
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

Why would we bother to go through all of these gyrations? There are several reasons, but the primary one is that this is how the real world works. You will notice a common theme as you study object-oriented design; the goal is to model real-world activities as closely as possible. In short, if you have a checking account with a balance of $1000, and want to make a deposit of $100, you don't go to the ATM and simply set your balance to $1100. In theory this would work, but it opens the door to honest mistakes as well as not-so-honest misconduct. Thus, you deposit $100 and let the bank figure out how to add it to your balance.

Besides the real-world modeling advantage, another advantage here is that we can control access to balance more closely. Basically, there is only one place and one place only, in the code that can actually change balance. Notice that the deposit() method does not directly change balance; to accomplish this, it must call setBalance().

Remember the example in last month's article where we did some range checking when we attempted to change balance? The same rule holds now that setBalance() is private.

private void setBalance(double bal) {

   if (bal < 0) {
      System,out.println ("Error!");
   } else {
      myAccount.balance = bal;
   }

It is possible that different points in the application may need to change balance. For example, there may be a method called addInterest() that needs to increase balance by the amount of interest earned. This is perfectly fine; however, to accomplish this, addInterest() must call setBalance().

One interesting note here is that this type of access control is not enforced by the compiler. If, for instance, deposit wanted to change the balance directly, it can.

public void deposit(double dep){
      balance = balance + dep;

};

This will not cause a compiler error but may well violate a programming practice established by you organization. This type of programming mistake would be caught during a code review. In any event, any direct changing of balance is limited to the actual class. No application could directly set balance.

We can extend our model to include withdrawal capabilities. Figure 4 shows the UML class diagram that corresponds to our design addition.

Figure 4: UML Diagram for Checking Account Class with withdrawal() method

Just like the deposit() method, we can create a withdrawal() method that utilizes setBalance().

public void withdrawal(double with){
   setBalance(balance - with);
};

Thus, our new CheckingAccount class is shown in

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 6: CheckingAccount.java with withdrawal() method

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()

It is important to understand that there may be some private implementation. In this CheckingAccount example, setBalance() is part of that private implementation. Thus, classes can have both public and private methods. In short, the application can call the public interface methods, but can't access either the private attributes or the private methods.

Conclusion

In this month's article, we further explored encapsulation by delving deeper into the topic of data hiding. Data hiding is one of the most important concepts of object-oriented design. Data hiding provides a much higher level of security for your class as well as providing many programming advantages.

Next month, we will continue our banking theme by designing a class for an ATM—an example that is quite popular in illustrating object-oriented design concepts.

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 3 of 3



Comment and Contribute

 


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

 

 


Enterprise Development Update

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

Sitemap | Contact Us

Rocket Fuel