Bruce Eckel's Thinking in Java Contents | Prev | Next

Interface and implementation

Access control is often referred to as implementation hiding. Wrapping data and methods within classes (combined with implementation hiding this is often called encapsulation) produces a data type with characteristics and behaviors, but access control puts boundaries within that data type for two important reasons. The first is to establish what the client programmers can and can’t use. You can build your internal mechanisms into the structure without worrying that the client programmers will think it’s part of the interface that they should be using.

This feeds directly into the second reason, which is to separate the interface from the implementation. If the structure is used in a set of programs, but users can’t do anything but send messages to the public interface, then you can change anything that’s not public (e.g. “friendly,” protected, or private) without requiring modifications to their code.

We’re now in the world of object-oriented programming, where a class is actually describing “a class of objects,” as you would describe a class of fishes or a class of birds. Any object belonging to this class will share these characteristics and behaviors. The class is a description of the way all objects of this type will look and act.

In the original OOP language, Simula-67, the keyword class was used to describe a new data type. The same keyword has been used for most object-oriented languages. This is the focal point of the whole language: the creation of new data types that are more than just boxes containing data and methods.

The class is the fundamental OOP concept in Java. It is one of the keywords that will not be set in bold in this book – it becomes annoying with a word repeated as often as “class.”

For clarity, you might prefer a style of creating classes that puts the public members at the beginning, followed by the protected, friendly and private members. The advantage is that the user of the class can then read down from the top and see first what’s important to them (the public members, because they can be accessed outside the file) and stop reading when they encounter the non-public members, which are part of the internal implementation. However, with the comment documentation supported by javadoc (described in Chapter 2) the issue of code readability by the client programmer becomes less important. 

public class X {
  public void pub1( ) { /* . . . */ }
  public void pub2( ) { /* . . . */ }
  public void pub3( ) { /* . . . */ } 
  private void priv1( ) { /* . . . */ } 
  private void priv2( ) { /* . . . */ } 
  private void priv3( ) { /* . . . */ } 
  private int i; 
  // . . . 
}

This will make it only partially easier to read because the interface and implementation are still mixed together. That is, you still see the source code – the implementation – because it’s right there in the class. Displaying the interface to the consumer of a class is really the job of the class browser , a tool whose job is to look at all the available classes and show you what you can do with them (i.e. what members are available) in a useful fashion. By the time you read this, good browsers should be an expected part of any good Java development tool.

Contents | Prev | Next