3.12 ABSTRACT CLASSES AND INTERFACES


3.12 ABSTRACT CLASSES AND INTERFACES

Abstract classes are very important to object-oriented programming. While the notion of an abstract class is common to both C++ and Java, the latter also supports a variant thereof—interfaces. A Java interface is an abstract class that is not allowed to contain any implementation code at all for any of the member functions. An interface is also not allowed any data members that can be given values on a per object basis.[13]

In general, a class is abstract if it is not possible to construct objects from that class. This can happen for a variety of reasons. In C++, if one or more of the member functions of a class is declared to be pure virtual, then you cannot make objects from that class. In Java, if you declare a class to be abstract explicitly, you are not allowed to make any objects from that class.

The reader might ask: If you cannot make objects from a class definition, what good is the class? Here are some answers to this question:

  • An abstract class can lend organization to the other classes in a class hierarchy.

  • An abstract class can represent a specialized behavior, which when mixed with the other classes gives us classes with that behavior.

  • Abstract classes can help build up an implementation incrementally.

An abstract class can help with knowledge organization in an OO program by serving as a root class of a hierarchy of other concrete classes and thus pull together what might otherwise be disparate bits of knowledge encapsulated in the subclasses. A classic and frequently used example of this is the Shape hierarchy of classes shown in Figure 3.5. Obviously, while we can construct objects of type Circle, Rectangle, and so on, it would make no sense to construct an object of type Shape. Yet the class Shape serves a critical role, because it pulls together all the other classes into a single hierarchy. What do we mean by "pull together"? This question is actually deeper than it appears at first sight.

click to expand
Figure 3.5

What we mean by the Shape class pulling together the other classes has to do with inheritance and polymorphism. Taking advantage of inheritance, we could place in the Shape class all of the code that is common between its various subclasses, making our program more efficient. And, given a list of Shapes, some of which may actually be Circles, some Rectangles, and so on, we could invoke a function such as area() on the entire list. Polymorphism would then automatically cause the object-specific area() to be invoked on each Shape in the list. This assumes that we have at least declared area() as one of the functions for the root class Shape and that we have provided implementation code for area() in the subclasses.

Here is how you could define an abstract class Shape in C++:

      class Shape {      public:           virtual double area( ) = 0; //(A)           virtual double circumference() = 0; //(B)           //....           } 

Incorporating the symbol "=0" as we have in lines (A) and (B) tells the compiler that these two functions are pure virtual. A C++ class that has at least one pure virtual function is treated as an abstract class by the compiler; the compiler will not allow such a class to be instantiated into objects. The compiler expects no implementation code for a pure virtual function. Chapter 15 explains this point and consequences thereof in much greater detail.

An abstract class in Java is defined in the following manner:

      abstract class Shape {           abstract public double area( );           abstract public double circumference();           //.... } 

As you can see, Java requires that the class header start with the keyword abstract and, also, if your class includes any methods for which you do not intend to provide implementation code, the method declaration must also include the same keyword.

As we mentioned at the beginning of this section, Java also supports interfaces, which is a class that consists solely of abstract methods and of constants. You might ask: If C++ can make do with just abstract classes, why does Java need both abstract classes and interfaces? The answer to this question, to be given in detail in Chapter 15, basically has to do with the fact that C++ allows for multiple inheritance, while Java does not. A Java class is allowed to inherit implementation code from only one superclass. While this restriction eliminates many difficult programming issues associated with the use of multiple inheritance in C++, it creates its own program design limitations that are gotten around through the concept of an interface. A Java class can be a subclass of any number of interfaces.

Interfaces in Java are mostly used for lending specialized behaviors to classes. To illustrate this point, Figure 3.6 shows how the class ArrayList, which is a very useful class for constructing dynamically expandable arrays of objects, is implemented in the Java source code: In this class hierarchy, ArrayList is the only concrete class, meaning a class that can be instantiated to form actual objects. The part of the hierarchy that is shown vertically on the left illustrates how the implementation of ArrayList is built incrementally through the abstract classes AbstractCollection and AbstractList. ArrayList can inherit implementation code only from its superclasses AbstractCollection and AbstractList. In addition to this implementation code, ArrayList inherits "behaviors" directly from the interfaces List, Cloneable, and Serializable. ArrayList must provide implementation code for all the functions declared in all of these interfaces. ArrayList also inherits behaviors indirectly from the interface Collection.

click to expand
Figure 3.6

In this manner, every ArrayList object is also a List object. By the same token, every ArrayList object is also a Cloneable object, just as it is also a Serializable object and a Collection object. This implies that objects of type ArrayList can be manipulated polymorphically with respect to the interfaces declared in List, Cloneable, Serializable, and Collection.

Interfaces in Java are also used for grouping together related constants. When a class inherits from such an interface, the constants appear as if locally defined in the class. Such constants defined for interfaces are treated implicitly as final and static.[14]

The syntax for declaring a Java interface is

      interface Collection {           public boolean add( Object o );           public boolean remove ( Object o );           // other methods      } 

The methods declared in an interface are always public, implicitly so if their access privilege is not stated. Such methods are also not allowed to be static.

We say that a Java class implements an interface if the class provides implementation code for all the methods declared in the interface. The header of a class MyClass that implements an interface MyInterface must include keyword implements as shown below

      class MyClass implements MyInterface {          // .....          // implementation code for          // the methods declared in MyInterface          // .....      } 

Java interfaces are discussed in much more detail in Chapter 15.

[13]What's meant by "value on a per object basis" will become clear after we have presented the notion of a static class member in Section 3.12 of this chapter. The topic of static class members is discussed more fully in Chapter 11.

[14]The notion of the static member of a class is discussed briefly in Section 3.14 and in greater detail in Chapter 11. The modifier final, when applied to variables, acts like const in C++. There is a brief remark concerning this use of final in Java at the end of Section 3.6; a fuller discussion can be found in Chapter 7.




Programming With Objects[c] A Comparative Presentation of Object-Oriented Programming With C++ and Java
Programming with Objects: A Comparative Presentation of Object Oriented Programming with C++ and Java
ISBN: 0471268526
EAN: 2147483647
Year: 2005
Pages: 273
Authors: Avinash Kak

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net