Why Encapsulation Is Fundamental to OO

If you then create a subclass of Cabbie called PartTimeCabbie , and PartTimeCabbie inherits the implementation from Cabbie , changing the implementation of Cabbie directly affects the PartTimeCabbie class.

For example, consider the UML diagram in Figure 7.10. PartTimeCabbie is a subclass of Cabbie . Thus, PartTimeCabbie inherits the public implementation of Cabbie , including the method giveDirections() . If the method giveDirections is changed in Cabbie , it will have a direct impact on PartTimeCabbie and any other classes that might later be subclasses of Cabbie . In this subtle way, changes to the implementation of Cabbie are not necessarily encapsulated within the Cabbie class.

To reduce the risk posed by this dilemma, it is important that you stick to the strict is-a condition when using inheritance. If the subclass were truly a specialization of the superclass, changes to the parent would likely affect the child in ways that are natural and expected. To illustrate , if a Circle class inherits implementation from a Shape class, and a change to the implementation of Shape breaks Circle , then Circle was not truly a Shape to begin with.

How can inheritance be used improperly? Consider a situation in which you want to create a window for the purposes of a graphical user interface (GUI). One impulse might be to create a window by making it a subclass of a rectangle class:

class Rectangle {



}



class Window extends Rectangle {



}

In reality a GUI window is much, much more than a rectangle. It is not really a specialized version of a rectangle, as is a square. A true window might contain a rectangle (in fact many rectangles); however, it is really not a true rectangle. In this approach, a Window class should not inherit from Rectangle , but it should contain Rectangle classes.

class Window {



    Rectangle menubar;

    Rectangle statusbar;

    Rectangle mainview;



}

A Detailed Example of Polymorphism

Many people consider polymorphism the cornerstone of OO design. Designing a class for the purpose of creating totally independent objects is what OO is all about. In a well-designed system, an object should be able to answer all the important questions about it. As a rule, an object should be responsible for itself. This independence is one of the primary mechanisms of code reuse.

As stated in Chapter 1, polymorphism literally means many shapes . When a message is sent to an object, the object must have a method defined to respond to that message. In an inheritance hierarchy, all subclasses inherit the interfaces from their superclass. However, because each subclass is a separate entity, each might require a separate response to the same message.

To review the example in Chapter 1, consider a class called Shape . This class has a behavior called Draw . However, when you tell somebody to draw a shape, the first question they ask is likely to be, "What shape?" Simply telling a person to draw a shape is too abstract (in fact, the Draw method in Shape contains no implementation). You must specify which shape you mean. To do this, you provide the actual implementation in Circle and other subclasses. Even though Shape has a Draw method, Circle overrides this method and provides its own Draw method. Overriding basically means replacing an implementation of a parent with your own.

Object Responsibilty

Let's revisit the Shape example from Chapter 1 (see Figure 7.11).

Polymorphism is one of the most elegant uses of inheritance. Remember that a Shape cannot be instantiated . It is an abstract class because it has an abstract method, getArea() . Chapter 8 explains abstract classes in great detail.

However, Rectangle and Circle can be instantiated because they are concrete classes. Rectangle and Circle are both shapes; however, they obviously have some differences. Because Rectangle and Circle are both shapes, their area can be calculated. Yet, the formula to calculate the area is different for each. Thus, the area formulas cannot be placed in the Shape class.

This is where polymorphism comes in. The premise of polymorphism is that you can send messages to various objects, and they will respond according to their object type. For example, if you send the message getArea to a Circle class, you will invoke a completely different method than if you send the same getArea message to a Rectangle class. This is because both Circle and Rectangle are responsible for themselves . If you ask Circle to return its area, it knows how to do this. If you want a circle to draw itself, it can do this, too. A Shape object could not do this even if it could be instantiated. Notice that in the UML diagram, the getArea method in the Shape class is italicized. This designates that the method is abstract.

As a very simple example, imagine that there are four classes: the abstract class Shape , and concrete classes Circle , Rectangle , and Star . Here is the code:

public abstract class Shape{



    public abstract void draw();



}



public class Circle extends Shape{



    public void draw() {



        System.out.println("I am drawing a Circle");



    }

}



public class Rectangle extends Shape{



    public void draw() {



        System.out.println("I am drawing a Rectangle");



    }

}



public class Star extends Shape{



    public void draw() {



        System.out.println("I am drawing a Star");



    }

}

Notice that there is only one method for each class: draw . Here is the important point regarding polymorphism and an object being responsible for itself: The concrete classes themselves have responsibility for the drawing function. The Shape class does not provide the code for drawing; the Circle , Rectangle , and Star classes do this for themselves. Here is some code to prove it:

public class TestShape {



    public static void main(String args[]) {



        Circle circle = new Circle();

        Rectangle rectangle = new Rectangle();

        Star star = new Star();



        circle.draw();

        rectangle.draw();

        star.draw();



   }



}

Compiling This Code

If you want to compile this Java code, make sure that you set classpath to the current directory:

javac -classpath . Shape.java

javac -classpath . Circle.java

javac -classpath . Rectangle.java

javac -classpath . Star.java

javac -classpath . TestShape.java

Actually, when you compile a Java class (in this case TestShape ) and it -requires another class (let's say Circle ), the javac compiler will attempt to compile all the required classes. Thus, the following line will actually compile all the files in this example.

javac -classpath . TestShape.java

circle.draw();

rectangle.draw();

star.draw();

C:\>java TestShape

I am drawing a Circle

I am drawing a Rectangle

I am drawing a Star

public class Triangle extends Shape{



    public void draw() {



        System.out.println("I am drawing a Triangle");



    }

}

public class TestShape {



    public static void main(String args[]) {



        Circle circle = new Circle();

        Rectangle rectangle = new Rectangle();

        Star star = new Star();

        Triangle triangle = new Triangle ();



        circle.draw();

        rectangle.draw();

        star.draw();

        triangle.draw();



   }



}



C:\>java TestShape

I am drawing a Circle

I am drawing a Rectangle

I am drawing a Star

I am drawing a Triangle

public class TestShape {



   public static void main(String args[]) {



     Circle circle = new Circle();

     Rectangle rectangle = new Rectangle();

     Star star = new Star();



     drawMe(circle);

     drawMe(rectangle);

     drawMe(star);



   }



   static void drawMe(Shape s) {

     s.draw();

   }



}