Public Interface Methods

< Day Day Up >

Public Interface Methods

Both the constructors and the accessor methods are declared as public, and are part of the public interface. They are singled out because of their specific importance to the construction of the class. However, much of the real work is provided in other methods. As mentioned in Chapter 2, the public interface methods tend to be very abstract, and the implementation tends to be more concrete. For this class, we provide a method called giveDestination that is the public interface for the user to describe where she wants to go:

public void giveDestination (){



}

What is inside of this method is not important at this time. The main point here is that this is a public method, and it is part of the public interface to the class.

< Day Day Up >

Private Implementation Methods

Although all the methods discussed so far in this chapter are defined as public , not all the methods in a class are part of the public interface. Some methods in a class are meant to be hidden from other classes. These methods are declared as private :

private void turnRight(){

}



private void turnLeft() {

}

These private methods are simply meant to be part of the implementation, and not the public interface. You might ask who invokes these methods, if no other class can. The answer is simple ”you might have already surmised that these methods are called internally from the class itself. For example, these methods could be called from within the method giveDestination :

public void giveDestination (){



    .. some code



    turnRight();

    turnLeft();



    .. some more code



}

The point here is that private methods are strictly part of the implementation, and are not accessible by other classes.

< Day Day Up >

Conclusion

In this chapter we have gotten inside a class and described the fundamental concepts necessary for understanding how a class is built. Although this chapter takes a practical approach to discussing classes, Chapter 5, "Class Design Guidelines," covers the class from a general design perspective.

< Day Day Up >

References

Fowler, Martin. UML Distilled . Addison-Wesley Longman, 1997.

Gilbert, Stephen, and Bill McCarty. Object-Oriented Design in Java . The Waite Group, 1998.

Tyma, Paul, Gabriel Torok, and Troy Downing. Java Primer Plus . The Waite Group, 1996.

< Day Day Up >

Chapter 5. Class Design Guidelines

One of the primary goals of object-oriented (OO) programming is to model real-world systems in ways similar to the ways in which people actually think. Designing classes is the object-oriented way to create these models. Rather than using a structured, or top-down approach, where data and behavior are separate entities, the OO approach encapsulates the data and behavior into objects that interact with each other. Don't think of a problem as a sequence of events or routines operating on separate data files. Think of how your objects model real-world objects and how they interact with other real-world objects.

These interactions occur in a way similar to the interactions between real-world objects, such as people. Thus, when creating classes, you should design them in a way that represents the true behavior of the object. Let's use the cabbie example from previous chapters. The Cab class and the Cabbie class model a real-world entity. As illustrated in Figure 5.1, the Cab and the Cabbie objects encapsulate their data and behavior, and they interact through each other's public interfaces.

Figure 5.1. A cabbie and a cab are real-world objects.

graphics/05fig01.gif

When moving to OO programming for the first time, many people tend to still think in a structured way. One of the primary mistakes is to create a class that has behavior but no class data. In effect, they are creating a set of functions or subroutines in the structured model. This is not what you want to do, because it violates the concept of encapsulation.

As we have already discussed, OO programming supports the idea of making classes that are complete packages, encapsulating the data and behavior of a single entity. So, a class should represent a logical component, such as a taxicab.

This chapter presents several suggestions for designing solid classes. Obviously, no list such as this can be considered complete. You will undoubtedly add many guidelines to your personal list.

One of the better books pertaining to class design guidelines and suggestions is Effective C: 50 Specific Ways to Improve Your Programs and Designs by Scott Meyers. It offers important information about program design in a very concise manner.

< Day Day Up >