Chapter 5 ■ Object-Oriented Design Principles

Don’t be scared by the lengthy code—you can understand it. In this code, there are two major features to grasp:

•Product hierarchy: Shape is the base interface extended by DisplayFriendlyShape and PrinterFriendlyShape. Two flavors of the Circle and Rectangle classes are defined for each: display-friendly and printer-friendly shape.

•Abstract factory implementation: Made up of ShapeFactory as the base interface, and PrinterFriendlyFactory and DisplayFriendlyFactory as the concrete factories. PrinterFriendlyFactory creates only PrinterFriendlyCircle and PrinterFriendlyRectangle; similarly, DisplayFriendlyFactory creates DisplayFriendlyCircle and DisplayFriendlyRectangle.

The rest of the code is quite similar to the factory version of the program in Listing 5-12.

Java SDK employs the abstract factory pattern at numerous places. You would do well, for example, to check out and understand the following:

•javax.xml.transform.TransformerFactory

•javax.xml.xpath.XPathFactory

Parenthetical Note: For the OCPJP 7 exam, you need to understand the factory design pattern, by which the factory creates new instances of a product hierarchy based on the provided input. Outside the scope of the OCPJP 7 exam but nevertheless noteworthy is another way to implement the factory: reflection.

The main advantage of using reflection to implement the factory is that you can extend your product hierarchy without changing the implementation of factory or compromising the factory’s ability to create newly added classes.

The Data Access Object (DAO) Design Pattern

Suppose that you are at a multicultural fair with your family and you decide to take a ride on the carousel. You see a big panel with many buttons for operating the carousel. You ask the operator to start the carousel, adjust its

speed, and stop it. The operator, who knows how to use the panel, follows your instructions. He is providing you an abstraction from the complicated control panel. In fact, if you go to different carousel at the other end of the fair, you can instruct its operator in the same way and that operator will follow your instructions in the same way even though his panel is different from that of the first carousel. In essence, your family can take a ride on any carousel without understanding its operating panel because the knowledge to operate the machine is abstracted by the operator. The Data Access Object (DAO) design pattern provides you abstractions in an analogous way.

In real-life projects, you will encounter situations in which you want to make your data persist. You might use flat files (i.e., data files on your native OS), XML files, OODBMS, RDBMS, etc. In such situations, you can use the DAO design pattern. This design pattern abstracts the details of the underlying persistence mechanism and offers you an easy-to-use interface for implementing the persistence feature in your application. The DAO pattern hides the implementation details of the data source from its clients, thereby introducing loose coupling between your core business logic and your persistence mechanism. This loose coupling enables you to migrate from one type of persistence mechanism to another without any big-bang change.

139

Chapter 5 ■ Object-Oriented Design Principles

A DAO design pattern essentially separates your core business logic from your persistence logic.

Let’s examine the structure of the pattern, which is shown in Figure 5-4. DataSource represents a concrete persistence implementation such as a RDBMS, XML database, or even another system/repository. DAO provides an abstraction for the DataSource, hides the specific implementation level details, and provides a single interface for all different types of data sources. A Client is a user of DAO pattern that uses DataSource through DAO, and TransferObject is a data transfer object used as a medium to transfer the core objects.

creates

uses

TransferObject

Figure 5-4.  UML class diagram of DAO design pattern

Apart from the above-mentioned participants (Client, DAO, TransferObject, and DataSource), there could be one more participant for this pattern—DAOFactory. You may have multiple DAO objects, corresponding to all the different types of objects you want to store. You may define a factory (using the factory design pattern, as you did in the preceding section), which can have one method for each DAO object. Don’t worry…you’re going to implement a factory in your next example.

Assume that you want to implement the DAO design pattern in the FunPaint application. Here, you have a Circle class that you want to store in a persistent data store. Listing 5-15 shows the implementation of the pattern.

Listing 5-15.  Test.java

// Circle.java public class Circle {

private int xPos, yPos; private int radius;

public Circle(int x, int y, int r) { xPos = x;

yPos = y; radius = r;

}

public String toString() {

return "center = (" + xPos + "," + yPos + ") and radius = " + radius;

}

140

Chapter 5 ■ Object-Oriented Design Principles

public CircleTransfer getCircleTransferObject() { CircleTransfer circleTransfer = new CircleTransfer(); circleTransfer.setRadius(radius); circleTransfer.setxPos(xPos); circleTransfer.setyPos(yPos);

return circleTransfer;

}

// other members

}

// CircleDAO.java

public interface CircleDAO {

public void insertCircle(CircleTransfer circle); public CircleTransfer findCircle(int id); public void deleteCircle(int id);

}

// RDBMSDAO.java

public class RDBMSDAO implements CircleDAO { @Override

public void insertCircle(CircleTransfer circle) { // insertCircle implementation

System.out.println("insertCircle implementation");

}

@Override

public CircleTransfer findCircle(int id) { // findCircle implementation return null;

}

@Override

public void deleteCircle(int id) {

// deleteCircle implementation

}

}

// DAOFactory.java public class DAOFactory {

public static CircleDAO getCircleDAO(String sourceType) {

//This is a simple example, so we have listed only "RDBMS" as the only source type

//In a real-world application, you can provide more source types switch(sourceType){

case "RDBMS":

return new RDBMSDAO();

}

return null;

}

}

// CircleTransfer.java import java.io.Serializable;

141

Chapter 5 ■ Object-Oriented Design Principles

public class CircleTransfer implements Serializable { private int xPos;

private int yPos; private int radius; public int getxPos() {

return xPos;

}

public void setxPos(int xPos) { this.xPos = xPos;

}

public int getyPos() { return yPos;

}

public void setyPos(int yPos) { this.yPos = yPos;

}

public int getRadius() { return radius;

}

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

}

}

// Test.java public class Test {

public static void main(String[] args) { Circle circle = new Circle(10, 10, 20); System.out.println(circle);

CircleTransfer circleTransfer = circle.getCircleTransferObject(); CircleDAO circleDAO = DAOFactory.getCircleDAO("RDBMS"); circleDAO.insertCircle(circleTransfer);

}

}

Well, that’s quite a big program. Let’s go through it step by step. The Circle class belongs to your core business logic; apart from the other usual members, the Circle class contains a method—getCircleTransferObject()—that returns the CircleTransfer object with the required data. You define the CircleDAO interface with three methods commonly used with data sources. The RDBMSDAO implements CircleDAO with a concrete implementation to access the RDBMS data source. The CircleTransfer object plays a data carrier role between the main() method (which is acting as a Client) and DAO implementation (i.e., the RDBMSDAO class).

One more feature to be noted in the Listing 5-15 implementation is the use of the factory design pattern. In an application, there might be many DAO objects. For instance, in the FunPaint application you might have CircleDAO, RectangleDAO, SquareDAO, etc. You may define getter methods to get corresponding DAO object in a single DAO factory. In each method, you may return an appropriate DAO object based on the provided type, as you do in this example with the RDBMS type.

Here are the benefits of the DAO design pattern:

•The pattern introduces an abstraction: the DAO hides the implementation details of the actual data source from the core business logic. The business logic need not know about the nittygritty of the data source, which results in easy-to-understand, less complicated code.

142