GoF patterns
The GoF design patterns catalog organizes the design patterns into three groups:
| Creational Patterns. The patterns in this group deal with the instantiation of objects within a system. Examples of patterns in this group are Factory Method and Singleton. |
|
| Structural Patterns. The patterns in this group deal with the organization of a classes within a system. Examples of patterns in this group are Facade and Adapter. |
|
| Behavioral Patterns. The patterns in this group deal with the assignment of responsibility to the classes present in an application, how information is passed around the system and the flow of control within the system. Examples of patterns in this group are Command and Observer. |
It is beyond the scope of this chapter to look in detail at each of the GoF patterns, but it is important to look at how patterns might be applied when using Rational Application Developer. Patterns can be applied from the outset when designing a system, but often a design is arrived at and must be refactored so that the design is improved by the application of a specific GoF pattern.
The comprehensive support built into Rational Application Developer for the refactoring of code can be put to good use when applying patterns. In addition, the ability to visualize classes in UML class diagrams is invaluable when applying patterns and looking for classes within an application that require a pattern to be applied. Additional support for patterns, through the Pattern Explorer view, is available in Rational Software Architect and Rational Software Modeler.
To demonstrate the kind of refactoring that would be undertaken using Rational Application Developer when applying a specific pattern, we consider an existing design example where the application of the Singleton pattern improves the design. Refactoring is the process of changing software so that it performs the same function as before but where the software structure has been changed. Refactoring includes changing the names of methods in a class, changing the name of a class, or adding and removing classes.
Figure | -6 shows a class diagram that includes two classes present in an application.
Figure 6-6 Classes before refactoring to apply the Singleton pattern
In this case both classes take responsibility for creating their own connection to a database. A better design is to delegate the creation the database connections to an object that is guaranteed to be present only once within the system. It is decided by the developer, in this case, that the Singleton pattern should be applied in the form of a database manager class that manages the creation of database connections. Figure | -7 shows the class diagram after refactoring to apply the Singleton pattern.
Figure 6-7 Classes after refactoring to apply the Singleton pattern
|
Note: Additional support for patterns, specifically the automatic application of patterns, is available in Rational Application Developer through exemplar authoring and Java Emitter Templates (JET). This is covered in detail in Chapter | , Accelerating development using patterns. |
|
ibm.com/redbooks |