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:
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.
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.
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.
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 PatternsThese 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:
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
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. |