Chapter 5 ■ Object-Oriented Design Principles

Use inheritance when a subclass specifies a base class, so that you can exploit dynamic polymorphism. In other cases, use composition to get code that is easy to change and loosely coupled. In summary, favor composition over inheritance.

Points to Remember

Here are some design principles and terminological nuances you should have under your belt when you take the OCPJP 7 exam:

•Adhere to the OO design principle of “favor composition over inheritance.” Composition encourages you to follow another useful OO design principle: “program to an interface, not to an implementation.” This second injunction means that the functionality of a class should depend only on the interface of another abstraction and not on the specific implementation details of that abstraction. In other words, implementation of a class should not depend on the internal implementation aspects of the other class. Wherever suitable, composition is the technique of choice.

•In OOP, there are many terms related to composition, such as association and aggregation. Association is the most general form of a relationship between two objects, whereas composition and aggregation are special forms of association. In general, the terms aggregation and composition are used interchangeably. Although these two terms are very similar, they do have a subtle difference. In composition, the lifetime of the contained object and the container object is the same, whereas that is not the case with aggregation. For example, a computer object and a CPU object share a composition relationship, while a library object and a book object share an aggregation relationship.

Design Patterns

In the object-oriented world, the concepts behind design patterns are well established. As an object-oriented programming language developer and as a candidate for OCPJP 7 exam certification, you must know about design patterns and related concepts.

The literal meaning of design pattern in programming is a repeatable solution applicable to solve a generic design problem. Experienced programmers and designers learn from their experience and formulate solutions to frequently recurring design problems. Design patterns capture and replicate the experience of experienced software designers.

“Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” —Design Patterns: Elements of Reusable Object-Oriented Software [Aside: This classic 1994 book popularized design patterns. Four authors (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) wrote this book and for this reason it became known as the “Gang of Four” (GoF) book. The patterns covered in this chapter are mostly GoF patterns.]

A clarification before we delve into various design patterns: design patterns are design solutions. They are not ready-made solutions like code in a library, which you can take off the shelf and use as needed when you program. Design patterns instead provide template solutions that need to be fine-tuned based on the given context.

123

Chapter 5 ■ Object-Oriented Design Principles

// ShapeArchiver.java public class ShapeArchiver {

public void update(Circle circle) { System.out.println("ShapeArchiver::update"); // update implementation

}

}

//Canvas.java public class Canvas {

public void update(Circle circle) { System.out.println("Canvas::update"); //update implementation

}

}

//Test.java

public class Test {

public static void main(String []s) {

Circle circle = new Circle(10, 10, 20); System.out.println(circle); circle.setCanvas(new Canvas()); circle.setShapeArchiver(new ShapeArchiver()); circle.setRadius(50); System.out.println(circle);

}

}

This program prints the following:

center = (10,10) and radius = 20 Canvas::update ShapeArchiver::update

center = (10,10) and radius = 50

Well, this implementation works as intended—but there is a problem. There is a tight coupling between the subject (Circle class) and both of the observers (ShapeArchiver and Canvas). Here are the consequences of a tightly coupled design:

•The subject class (Circle) knows about the specific observer classes. As a result, if you change observer classes, you need to change subject class, too. (Hmm, not so good.)

•If you want to add or remove an observer, you cannot do it without changing the subject.

•You cannot reuse either the subject or the observer classes independently.

Okay, there are some problems in the previous implementation. Is there a way to eliminate these problems? Check out the new implementation in Listing 5-6.

125

Chapter 5 ■ Object-Oriented Design Principles

Listing 5-6.  Test.java

// Circle.java

import java.util.Observable;

public class Circle extends Observable { private Point center;

public void setCenter(Point center) { this.center = center; setChanged(); notifyObservers();

}

public void setRadius(int radius) { this.radius = radius; setChanged(); notifyObservers();

}

private int radius;

public Circle(int x, int y, int r) { center = new Point(x, y); radius = r;

}

public String toString() {

return "center = " + center + " and radius = " + radius;

}

}

//Point.java class Point {

private int xPos; private int yPos;

public Point(int x, int y) { xPos = x;

yPos = y;

}

public String toString() {

return "(" + xPos + "," + yPos + ")";

}

}

//Canvas.java

import java.util.Observable; import java.util.Observer;

public class Canvas implements Observer { @Override

public void update(Observable arg0, Object arg1) { System.out.println("Canvas::update");

// actual update code elided ...

}

}

126

Chapter 5 ■ Object-Oriented Design Principles

// ShapeArchiver.java import java.util.Observable; import java.util.Observer;

public class ShapeArchiver implements Observer{ @Override

public void update(Observable arg0, Object arg1) { System.out.println("ShapeArchiver::update"); // actual update code elided ...

}

}

// Test.java public class Test {

public static void main(String []s) {

Circle circle = new Circle(10, 10, 20); System.out.println(circle); circle.addObserver(new Canvas()); circle.addObserver(new ShapeArchiver()); circle.setRadius(50); System.out.println(circle);

}

}

This program prints the following:

center = (10,10) and radius = 20 ShapeArchiver::update Canvas::update

center = (10,10) and radius = 50

Well, the output is the same as for the previous version. Did you achieve anything better? Yes, you did. This new implementation is a loosely coupled implementation. The subject—Circle class—does not know about the concrete observer classes, and the observers do not know about the concrete subject. Consequently, both the subject and observers can now be used independently and changed independently. Furthermore, you can add and remove observers from the subject without changing the subject class.

This example is an implementation of the Observer design pattern. This design pattern is useful in cases in which you have a subject to be monitored by a couple of observers. These observers need to be informed whenever the subject gets changed. The Observer design pattern creates loose coupling between the subject and the observers.

Java supports an abstract class with the name Observable and an interface named Observer (both provided in the java.util package) to implement the Observer design pattern. The Circle class is extended from Observable, which tags the Circle class as a subject. The Canvas and ShapeArchiver classes implement the Observer interface, and hence implement the update() method. Whenever the state of subject is changed, you call the setChanged() method followed by notifyObservers(), which is implemented in the Observable class. The notifyObservers() method calls all observers registered earlier for that subject.

We hope that this example gives you a good handle on design patterns. In the rest of this chapter, we will explore in detail several more important design patterns.

127