November 24, 2014
Hot Topics:

Java Language Security: Controlling Access to a Class

  • December 8, 2006
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

This series, The Object-Oriented Thought Process, is intended for someone just learning an object-oriented language and who wants to understand the basic concepts before jumping into the code, or someone who wants to understand the infrastructure behind an object-oriented language he or she is already using. These concepts are part of the foundation that any programmer will need to make the paradigm shift from procedural programming to object-oriented programming.

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 standard edition, J2SE 5.0, at http://java.sun.com/j2se/1.5.0/download.jsp to compile and execute these applications. I often reference the Java J2SE 5.0 API documentation and I recommend that you explore the Java API further. Code listings are provided for all examples in this article as well as figures and output (when appropriate). See the first article in this series for detailed descriptions for compiling and running all the code examples.

This column covers the topic of Java Class access security. Here, you explore a very basic aspect of security that a Java developer would be concerned about at the design level.

Security in Reuse

Classes are designed, implemented, and deployed with reuse in mind. Although there are situations when a class may be created for a very specific use, perhaps even a one-time use, the basic object-oriented approach is to design a class with reuse as a primary goal.

It is an interesting academic exercise to debate the various ways that a class can be used, and reused. However, there are really only two distinct ways that a class can utilize a previously written class: by extending it (inheritance) or by referencing it (composition).

Note: For this discussion, you will consider a reference to be either a reference to an object passed into the class as a parameter or an object created in the class itself. These concepts will be explored in more detail later in this article.

Thus, you can say that, in general, a class can be reused in two different ways, composition (has-a) and inheritance (is-a).

For example, composition can be used when various Car classes incorporate an Engine class. Consider the real-life scenario where two different car models use the same type of engine—in these cases, the cars are a composite (has-a) of the engine and other reusable parts.

class Engine {


}

class Car01 {

   Engine engine = new Engine();

}

class Car02 {

   Engine engine = new Engine();

}

Listing 1: Composition Reuse

In the inheritance model, you can say that an Employee is-a type of Person. You can create a Person class that has a name attribute because you can assume that all people have a name. Thus, if the Employee inherits from Person, the Employee will inherit the name attribute.

The beauty of the inheritance approach is that you then can create a class called Vendor (assuming a vendor is a Person) and have the Vendor class inherit from Person as well. Thus, the Employee class and the Vendor class can both utilize, and reuse, the code contained in the Person class.

class Person {

   String name;

}

class Employee extends Person {

}

class Vendor extends Person {

}

Listing 2: Inheritance Reuse

Uncontrolled access in reuse

While the concept of reuse is a very powerful design mechanism, it does present some security issues – there is the potential of providing unlimited access to the class and the attributes and methods of that class.

Let me illustrate this concept by creating a class called CheckingAccount that includes two attributes, accountNumber and accountBalance. To provide uncontrolled access to these attributes, you declare them as public—you will soon see why this is not a good design practice.

Note: You should immediately balk at declaring these attributes as public. By dong so, you are breaking one of the most important object-oriented rules—all attributes must be declared private with access to them controlled via methods.
class CheckingAccount {

   public String accountNumber;
   public double accountBalance = 1000000.00;

}

Listing 3: Uncontrolled Access

The problem with this approach can be seen immediately by creating another class called AccountList that uses composition to use the CheckingAccount class. Because the attributes were declared as public, the author of the class can actually inspect the contents of the attributes, for example, the accountBalance.

class AccountList {
   public static void main(String args[]) {
      CheckingAccount myList = new CheckingAccount();
      System.out.println("Balance = " + myList.accountBalance);
   }
}

Listing 4: Inspecting Unprotected Attributes

When this class is executed as an application, you obtain the results as seen in Figure 1.

Figure 1: Obtaining Access to an Unprotected Attribute

Complete control of access in reuse

Although using the public access modifier for attributes breaks the encapsulation rule, you can go to the other extreme by making all of the attributes private.

class CheckingAccount {

   private String accountNumber;
   private double accountBalance = 1000000.00;

}

Listing 5: Controlled Access

Now, when you attempt to execute the same application (see Listing 4), access to the accountBalance is prohibited—in fact, you can't even compile the code.

Figure 2: Compiler Controlling Access to an Protected Attribute





Page 1 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