This chapter is from the book
This chapter is from the book
This chapter is from the book
Java Design Patterns
The concept of design patterns is often heard discussed in connection with Java application design. Design patterns are used to help guide the development process. Design patterns do not represent complete, template-like solutions, but instead represent recommendations on how to solve certain recurring problems with Java development.
The concept of design patterns can be traced back to work that Christopher Alexander did with building construction architecture in the 1980s. Alexander noted that certain problems would consistently recur in building design and that certain proven solutions could be used to solve these problems. He referred to these proven solutions as design patterns.
A group of academics picked up on this work and wrote a seminal book on the subject titled, appropriately enough, Design Patterns: Elements of Reusable Object-Oriented Software. The authors of this text, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, are often referred to as the Gang of Four, and thus the text is often referred to as the GoF book. The authors of this text very succinctly applied the concept of design patterns to the process of developing good, object-oriented code. They used the Smalltalk language, but the solutions can easily be applied to any full-featured object-oriented language that supports polymorphism and a facility similar to Java interfaces.
Chapter 13 covers design patterns that apply to JDBC programming in more detail. What is important to note at this point is that design patterns have a significant impact on how JDBC will be used in an application. It should also be noted that design patterns can be applied at several different levels of the development process. Gamma, Helm, Johnson, and Vlissides refer to design patterns as taking the form of creational, structural, or behavioral patterns in relation to how the patterns will be used.
A design pattern that is often noted is the Model, View, Controller (MVC) design pattern. The MVC design pattern was originally applied to the Graphical User Interface (GUI) programming and describes the responsibilities of different portions of the application, as shown in Table 1–3.
As applied to a GUI application, the model portion of the application manages the data, the view displays the controls of the application (input fields, tables, list boxes), and the controller represents the event handlers for user-generated events: button clicks, list box choices, and others. In a GUI application being developed with an object-oriented language, these components would represent objects (and the class definitions for the object) that would be designed to provide for the behaviors, the responsibilities described in Table 1–3.
Table 1-3 MVC Design Pattern
| Component |
Responsibility |
| Model |
Manages the application state, the data the application is using. |
| View |
Renders the portion of the application visible to the user. |
| Controller |
Responds to user gestures and interfaces with the model to control the application. |
Table 1-4 EE Components by Tier
| ier |
MVC |
Component |
| Client |
View |
Applet, HTML, Java Webstart |
| Presentation |
Controller |
servlet, JSP page |
| Business |
Model |
Enterprise JavaBean, JavaBean |
| Resource |
n/a |
SQL |
But in order to apply this design pattern to a Web application, it is imperative that we identify which Web application components will implement the design. If we approach this design pattern using our multitiered architecture described earlier, we should expect that the view portion will be managed by the client tier, the controller will be managed the presentation tier, and the model will be managed by the business tier components. If we are using J2EE, our most likely candidate for each of these components is as follows (Table 1–4).
When viewed in this respect, the MVC pattern describes the responsibilities of the components being used and so would probably more accurately be described as an architectural design pattern. The MVC pattern alone does not describe how the specific components (the view component being used on the presentation tier, for example) would be designed. Other Java design patterns as shown later in this book do provide these details.
Using MVC as an architectural pattern, we do receive some high-level guidance about where JDBC code would be located. We would expect the JDBC calls to be placed in the components in the business tier. Located in that tier, the JDBC calls would retrieve data from the resource tier, and the Java code in the business tier would apply business logic and then return the data to the presentation tier, where it would be formatted for presentation to the user.