Identifying and Applying Design Patterns


Before writing lines of code, it is important to draw from the experience of others. There are some programming techniques that are reused so often, they have been given the name Design Patterns . In general, Design Patterns are reusable design solutions to common problem scenarios that occur during the development phase of an application. Design Patterns not only provide a consistent real-world design approach that developers can leverage to resolve development issues, but they also provide the capability to instill flexibility, scalability, and manageability into the application's design.

Even if you are not familiar with the term Design Patterns, there is a possibility that you have been incorporating patterns in your code. For example, certain Java Foundation Classes (JFC), also known as Swing, use the Model-View-Controller (MVC) design pattern, where:

  • Model represents the business logic and data associated with an application.

  • View represents the presentation data.

  • Controller represents the decision making component of an application.

For example, in a Swing GUI that displays a table of data, the JTable provides the view, the TableModel provides the model, and your application provides the control.

The Model-View-Controller Architecture (MVC)

Like many object-oriented techniques, the MVC architecture originated in the Smalltalk programming language. The fundamental idea behind MVC is to minimize the coupling between objects by aligning them with a specific set of responsibilities. In this case, the responsibilities are maintaining state and persistent data (Model), rendering the data for presentation (View), and executing application logic (Control). Figure 6.1 illustrates the MVC architecture.

Figure 6.1. The objects in a Model-View-Controller architecture have a specific set of responsibilities.

graphics/06fig01.gif

As illustrated in Figure 6.1, the View sends Queries to the Model to get the data that it will render and display. The View also sends User Events to the Controller, causing the controller to perform workflow and application logic on behalf of the user. The Controller sends model changes to the Model to notify which persistent data must be made available for viewing. The Model, in response, notifies the View of these changes through a change notification message, causing the View to update the displayed data.

The Model-View-Controller pattern is arguably the most fundamental design pattern behind J2EE itself; it provides a clear separation of system duties into distinct domains that are prevalent in almost every J2EE distributed system. For example, implementing a basic J2EE application architecture based on MVC would be represented as illustrated in Figure 6.2, where:

Figure 6.2. A basic J2EE application architecture based upon the MVC design pattern.

graphics/06fig02.gif

  • JavaServer Pages fall into the View (presentation) domain.

  • Servlets fall in the Control (data/flow orchestration) domain.

  • Enterprise JavaBeans (Entity beans) fall in the Model (data) domain.

Being such a significant influence on the J2EE architecture, it is very important that J2EE application developers have a firm understanding of the Model-View-Controller architecture.

Note

The J2EE Application Programming Model is based upon the MVC design pattern, as discussed in Chapter 5, "The J2EE Architecture and APIs."


One of the most difficult steps in starting a new project is identifying the system boundaries and the interaction between the components. When designing an enterprise J2EE application, it is extremely helpful to leverage the MVC design pattern to ensure the system boundaries and interaction between the components is established and well defined.

Note

Each component of an enterprise J2EE application typically falls into one of the three domains: Model, View, or Control.


The MVC architecture can also be modeled using the UML Activity Diagram. This is a very powerful mechanism to visualize and communicate the flow sequence of the J2EE application.

The mapping of a use case flow of events to an activity diagram involves applying swimlanes to the activity diagram to identify which component is performing the activity. For this reason, we can label the swimlanes View, Controller, and Model. There are a variety of requirement scenarios that dictate what J2EE components will be used towards the design of an application. A very typical J2EE application has a servlet that formats the data for viewing, Session beans to perform the workflow, and entity beans to represent the persistent data. As a UML activity diagram, this typical J2EE application can be modeled in a UML Activity diagram as shown in Figure 6.3.

Figure 6.3. A UML Activity Diagram uses swimlanes to map J2EE components to the MVC design pattern.

graphics/06fig03.gif

A complete Activity diagram used in the analysis of an enterprise application is provided in the Truck Rental case study later in this chapter.

The Gang of Four Design Patterns

These Design Patterns were originally organized by the "Gang of Four" hence, the reason why they are commonly known as "GoF" patterns in the development community. The term "Gang of Four" refers to the four authors of the book Design Patterns: Elements of Reusable Object-Oriented Software : Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. These Design Patterns are organized into the following three major pattern categories:

  • Creational , which are concerned with the way instances of an object are created.

  • Structural , which focus on the associations between objects.

  • Behavioral , which concentrate on the communication between objects.

It is very likely that you can use many of these patterns to help design your Class Diagrams and Interaction Diagrams. For example, the UML Sequence Diagram models the interaction between objects. From the sequence diagrams, Behavioral Design Patterns can be identified which define the communication between objects.

It is highly recommended that you become familiar with Design Patterns. Your entire software development process will become much more efficient. A classification summary of the GoF Design Patterns is represented in Table 6.1.

Table 6.1. A Classification Summary of GoF Design Patterns

Creational

 

Factory Method

Defines an interface for creating an object

Abstract Factory

Provides an interface for creating families of related or dependent objects without specifying their concrete class

Builder Pattern

Separates the construction of a complex object from its representation

Prototype Pattern

Specifies the kinds of objects to create using a prototypical instance

Singleton Pattern

Ensures a class only has one instance

Structural

 

Adapter Pattern

Converts the interface of a class into another interface that the client expects

Bridge Pattern

Decouples an abstraction from its implementation so the two can vary independently

Composite Pattern

Composes objects into tree structures to represent part-whole hierarchies

Fa §ade Pattern

Provides a unified interface to a set of interfaces in a subsystem

Flyweight Pattern

Uses sharing to support large numbers of fine-grained objects efficiently

Proxy Pattern

Provides a surrogate or placeholder for another object to control access to it

Behavioral

 

Observer Pattern

Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified

Mediator

Defines an object that encapsulates how a set of objects interact

Chain of Responsibility

Avoids coupling the sender of a request to its receiver allowing more than one object to handle the request

Template Pattern

Defines the skeleton of an algorithm in an operation, deferring some steps to subclasses

Interpreter

Given a language, defines a representation for its grammar along with an interpreter that uses the representation

Strategy Pattern

Encapsulates a family of algorithms allowing them to vary independently from the client that uses them

Visitor Pattern

Represents an operation to be performed on the elements of an object structure

State Pattern

Allows an object to alter its behavior when its internal state changes

Command Pattern

Encapsulates a request as an object

Iterator Pattern

Provides a way to access the elements of an aggregate object sequentially

The components of the J2EE architecture make extensive use of design patterns. Specific examples of how design patterns are used with EJBs are covered in the next section.



BEA WebLogic Platform 7
BEA WebLogic Platform 7
ISBN: 0789727129
EAN: 2147483647
Year: 2003
Pages: 360

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net