Chapter 4

Advanced Class Design

Identify when and how to apply abstract classes

Construct abstract Java classes and subclasses

Create top-level and nested classes

Use enumerated types

You learned the basic concepts of OOP and used them to build Java programs in the preceding chapter. In this chapter, you will learn advanced concepts in OOP, support from the Java language, and the nitty-gritty of these concepts.

In the opening section, you will learn about abstract classes and their uses in practical situations. The second and third sections cover two useful and frequently used keywords, final and static. The fourth section explores the variant flavors of nested classes: static nested classes, inner classes, local inner classes, and anonymous inner classes. The final section discusses enum data types, which were introduced in Java 5.

Some of the concepts in this chapter, especially nested classes and their variants, are not easy to understand on first reading. Although we endeavor to present the more difficult concepts such as anonymous classes and nested interfaces in an easy-to-understand manner, the best way for you to get the hang of them is to write programs using them.

For the OCPJP 7 exam, you need to know all these concepts inside out. This chapter serves to deepen your knowledge of the Java language and directly prepare you for the OCPJP 7 exam.

Abstract Classes

In many programming situations, you want to specify an abstraction without specifying implementation-level details. In such cases, you can use either abstract classes or interfaces supported by the Java platform. Abstract classes are used in cases when you want to define an abstraction with some common functionality. We will discuss interfaces in detail in the next chapter and will focus only on abstract classes in this section.

87

Chapter 4 ■advanCed Class design

You cannot create instances of an abstract class. Then, you may ask, why should I use an abstract class? Abstract classes are quite useful in OOP and are recommended strongly for the following reasons:

•Abstract classes define an abstraction and leave concrete implementation details to subclasses. An abstract type may have various flavors and hence different implementations; abstract classes provide the right platform for subclasses to achieve it. If an abstract type and its subclasses (concrete implementations) are well defined, then the users of such classes can employ runtime polymorphism. Runtime polymorphism is desirable since it introduces loose coupling among objects.

•Another reason to favor abstract classes is their ability to offer default implementation. Subclasses of the abstract class may specialize the default implementation if required.

•Abstract classes are the perfect placeholder for common functionality required in almost all of the subclasses of the abstract class.

Recall the FunPaint application you developed in the last chapter. The Shape class provides an abstraction of the different shapes you can draw in the FunPaint application. You can create objects of Shapes such as Square and Circle, but does it make sense to create an object of Shape class itself directly? No, there is no real-world object named Shape. In fact, Shape is a general-purpose abstraction that can be replaced by any proper shape like Circle.

The Shape class can be rewritten as an abstract class:

abstract class Shape {

public double area() { return 0; } // default implementation // other members

}

You prefix the abstract keyword before the class definition to declare the class as an abstract class. Let’s try creating an object of Shape:

Shape shape = new Shape();

For this statement, the compiler gives an error of "Shape is abstract; cannot be instantiated". In the Shape class definition, there is a method called area() that returns the area of a particular shape. This method is applicable for all shapes, and that’s why it’s in this base class Shape. However, what should the implementation of the area() method in the Shape class be? You cannot provide a default implementation; implementing this method as return 0; is a bad solution, although the compiler would happily accept it. A better solution is to declare it as an abstract method, like so:

public abstract double area(); // note: no implementation (i.e., no method body definition)

Similarly to declaring a class abstract, you declare the method area() as abstract by prefixing the method with the abstract keyword. The main difference between a normal method and an abstract method is that you don’t provide a body for an abstract method. If you provide a body, it will become an error, like so:

public abstract double area() { return 0; } // compiler error!

You get a compiler error for this definition: "abstract methods cannot have a body". Okay, fine! You cannot provide a body of the abstract method, but then what is the significance of an abstract method? An abstract class promises certain functionality through abstract methods to all its clients (users of this abstraction). An abstract method declaration forces all the subclasses to provide an implementation of that abstract method. If a derived class

88

Chapter 4 ■Advanced Class Design

does not implement all the abstract methods defined in the base class, then that derived class should be declared as an abstract class, as in the following example:

abstract class Shape {

public abstract double area(); // no implementation // other members

}

class Rectangle extends Shape { }

This snippet results in a compiler error of "Rectangle is not abstract and does not override abstract method area() in Shape". To fix this, you need to declare the derived class abstract or provide a definition of the area() method in the derived class. It does not make sense to declare Rectangle as abstract; so you can define the area() method like so:

class Rectangle extends Shape { private int length, height;

public double area() { return length * height; } // other members ...

}

Now let’s discuss another scenario where a common functionality needs to be supported by all the shape objects. For instance, each object could be drawn inside another shape object, which means each shape object has a parent (i.e., containing) object. As pointed out earlier, abstract classes are the best place to put a common functionality.

public abstract class Shape { abstract double area(); private Shape parentShape;

public void setParentShape(Shape shape){ parentShape = shape;

}

public Shape getParentShape(){ return parentShape;

}

}

This abstract class defines an attribute and two methods that will be available for all its subclasses. Useful, isn’t it?

Points to Remember

Master the following points about abstract classes and abstract methods, as they might well come up in the OCPJP 7 exam:

•The abstract keyword can be applied to a class or a method but not to a field.

•An abstract class cannot be instantiated. You can, however, create reference variables of an abstract class type. In fact, you can create objects of the classes derived from an abstract class and make the abstract class references refer to the created derived class objects.

•An abstract class can extend another abstract class or can implement an interface.

•An abstract class can be derived from a concrete class! Although the language allows it, it is not a good idea to do so.

89