January 17, 2021
Hot Topics:

Exploring Encapsulation

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

Why is data hiding so important? As stated earlier, perhaps the most important reason is access to the attributes. Consider the following line of code in an uncontrolled public access to the balance attribute.

myAccount.balance = -40.00;

In this line, balance is set to a negative number, -40. Obviously, we probably do not want to set a bank balance to a negative number (overdrafts notwithstanding). To prevent this, we would have to do a simple check in the code.

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

This works all right when there is only a single place to set balance. However, if we set the balance in multiple places, we would have to have this error checking in all of these locations.

One of the advantages of using a setter is that we can control access to the attribute and also do the error checking in a single place.

public void setBalance(double bal) {

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

Thus, by using a setter to control access to the attribute, we can ensure that balance NEVER gets set to a negative number. As an added benefit, if at some time that you decide that the minimum balance should be 100 (perhaps the overdraft limit), you only have to make the change to the error checking code in one place. I can set the balance in multiple places, and they all are controlled by the code in setBalance().


Why is data hiding important to getters as well as setters? In fact, controlling access to getters is very important. Consider the problem of hiding information from people who should not be able to access the data. The most obvious application for this would be that of passwords. By making the balance attribute private, other objects can only retrieve the value of balance if the getter allows access. Consider the following code.

public double getBalance(String pwd){   if (pwd != "entry") {      System.out.println("Error!");   } else {      return balance;   }   return 0;}

By using the getter, we can control access to balance. In effect, the data is hidden.

Note: This error-handling example is used to illustrate the concept of data hiding. In practice, exceptions would be a better way to handle errors such as these.


In this column, we explored the basic concepts of encapsulation. Encapsulation means that an object contains both its attributes and behaviors. Data hiding is an important part of encapsulation and the access designation private ensures that attributes are truly hidden. A very good rule to live by is that ALL attributes should be designated as private. In practice, you should never use a public designation for any attribute. All access to attributes should be accomplished via getters and setters. Next month, we will expand this discussion and add functionality to our CheckingAccount class. For example, we might want to add deposit() and withdrawal() methods.

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

This article was originally published on June 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