The Renaissance Programmer

OO Methodologies and Patterns

bject-oriented methodologies provide a general development process roadmap as well as a set of analysis and design techniques for modeling software systems. Methodologies are used by developers to build successful software systems. Following a methodology and using good development tools help, but it does not assure success. As Ward Cunningham and Ralph Johnson have agreed with Martin Fowler's statement that "projects fail despite the latest technology for lack of ordinary solutions" [Fowler 96]. What do you think they mean by "ordinary solutions"?

While methodologies give you the basic techniques to create an object model, they seldom provide the wisdom of how to build good analysis and design models. This is what patterns provide. Patterns are reusable solutions to analysis, design and implementation problems. They also include explanations of why and when to use them. They fill in the methodology gaps by providing direction and guidance for navigating the development process and for building understandable and implementable models. Recently, I have begun to immerse myself in three patterns books that I believe make major contributions to the industry by providing reusable models, ideas and concepts (i.e. patterns) for analysis and design. These are:

1. Analysis Patterns: Reusable Object Models by Martin Fowler [Fowler 96]
2. Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides ( Sometimes called the Gang of Four) [Gamma 95]
3. The Design Patterns Smalltalk Companion by S.R. Alpert, Kyle Brown, and Bobbie Woolf [Alpert 97]

There are other patterns books to read, but these three provide a wealth of analysis, design and implementation knowledge that is invaluable for the architect-builder who is designing and developing an object-oriented system.

Using patterns as part of your methodology

Lets consider how patterns fit in with a traditional OO methodology. The development team, following a typical OO development methodology, essentially deals with the views of business experts and owners, as well as their own architect, analyst, designer and builder views. The architect/analyst role concentrates on deriving the essential objects of the business as well as the basic structure in which to house those objects (e.g. a layered architecture). The designer evaluates what trade-offs need to be made to satisfy the design goals. The builder's role focuses on writing classes and methods that best support the design. Each step of the way, the developers are constructing a variety of models based on the views and applying patterns, either formalized in books and papers or informal ones that exist in their own minds, to the problem areas under consideration. Table 1, exemplifies the roles, responsibilities, models and patterns for this development process. It is loosely based on the Zachman framework.

Table 1 - Roles, Responsibilities, Models, Patterns

As you can see, the models from one view to another are quite similar. This is due to the natural strength of the object-oriented development process - the conceptual mapping between the analysis, design and implementation models. Patterns help in translating analysis models into design models and design models into an implementation model.

Analysis models provide simplified conceptual models that help us understand the problem. Analysis involves going beyond the surface requirements to come up with a mental model of what is going on in the problem. It involves answering the questions: "What are the real-world objects?" and "What do they do?" along with the requirements analysis question: "What will the system need to do"? Design models specify how the objects will do what they need to do. An implementation model is an executable model that gets the objects to do what they are designed to do, defining the classes and their behavior using an OO language such as Java, Smalltalk or C++.

Analysis patterns define what are the types (class interfaces) and what are their relationships in different domains. They cover concepts like organizational structure, accounting, warehousing, inventory, measurements of phenomena, planning, workflow, trading, ordering, material management, manufacturing, transaction processing, ad hoc query support, tabular presentation, scheduling, business rules, formulas etc. Analysis Patterns, the book, includes a number of these. More need to be written.

There are many similarities of basic conceptual entities between industries. A few years ago, I was doing some analysis and design to support genetic research at a pharmaceutical company. After slogging through a day and a half of discussing various techniques used in gene sequencing research and not making much progress, I suddenly realized that the system the scientists were asking for was essentially a warehousing system to store and retrieve DNA samples. This simplified the conceptual understanding of the problem considerably. I could apply the basic concepts (analysis patterns) of modeling the storing and retrieving of products in locations I had for warehousing to the storing and retrieving of DNA libraries in laboratories. Reading the book Analysis Patterns: Reusable Object Models makes me realize the commonality of analysis patterns that can span numerous business domains, (e.g. health treatment organizations and financial trading organizations).

The design patterns catalogued by the "gang of four" are recurring patterns of object configurations and interactions which solve problems through object collaboration. Design patterns use case-based reasoning to solve problems and capture expert experience for use by non-experts. Each pattern is a word that becomes part of a design vocabulary. The book, Design Patterns: Elements of Reusable Object-Oriented Software, contains a catalog of twenty three design patterns.

The authors grouped the design patterns into three categories: structural, behavioral and creational [Gamma 95]. The creational patterns provide ways to instantiate and build objects in terms of interfaces, not particular classes. Structural patterns focus on the composition of classes or objects. Behavioral patterns describe the ways classes or objects interact and how to distribute responsibility to provide flexible solutions.

One criticism of the design patterns is that they are too academic for use in developing business applications. Wishing to help dispel this idea, I have listed below a short and extremely simplified synopsis of each pattern that supports the idea that each design pattern is a set of one or more collaborating objects to be used by designers to fix design problems and ensure flexible designs.

1. The Structural patterns:
   • Adapter - an adapter is an object that provides translation services for a client to a server object. You can vary the interface to an object by using adapters.
   • Bridge - a bridge is a relationship between two class hierarchies which design a relationship that lets the interface for objects vary as well as their implementations.
   • Composite - a composite is a complex object that is composed of other composite objects as well as simple leaf objects. The composite objects behave just like a single object. You can easily vary the parts of a composite object.
   • Decorator - an object that adds behavior to another object by decorating it without subclassing.
   • Facade - an object that is the interface to a subsystem of objects. You can vary the facade presented to client object requesting the services provided by the subsystem.
   • Flyweight - an object that shares its state with other objects thus making them "lighter " (using less storage).
   • Proxy - an object that stands in for its subject objects and controls access to it. Using a proxy you can vary how an object is accessed and where it is located.
2. The Behavioral patterns:
   • Chain of responsibility - a "chained" object collaboration that responds to a message by "sending the message down the chain until a member of the chain can respond to it. You can vary what object responds to the message.
   • Command - an objectified action that can be "executed". You can vary when to fulfill the command and who is responsible for the request.
   • Interpreter - object structure with interpretive behavior for a simple language. You can vary the grammar of the language.
   • Iterator - an object which can access and traverse an aggregate's elements.
   • Mediator - object which directs and coordinates related objects
   • Memento - object collaboration with restorative behavior . Holds information of an object which has changed.
   • Observer - object collaboration with update and change notification behavior where the dependent objects are kept in sync with the observed object.
   • State - object collaboration with state-dependent behavior. You can vary state and the subsequent behavior of the object.
   • Strategy - object collaboration with policy dependent behavior where the policies or algorithms of an object can vary.
   • Template Method - class collaboration with customizable behavior for a shared basic routine
   • Visitor - object collaboration for adding operations on a composite object structure without changing classes
3. The Creational patterns:

• Abstract Factory - a creational collaboration for creating a family of customized parts of a Product using inheritance
• Builder - a creational collaboration for creating a Product by giving the builder the parts and letting him put it together
• Factory Method - getting default parts by delegating to subclasses for their part instantiations
• Prototype - creating an object from a copy of an existing object - The Prototype.
• Singleton - object creation mechanism for ensuring only a single instance of the object - the Singleton, exists.

Developing an object-oriented system is akin to writing a play. Plots and subplots ( like use cases and functions) are designed. Characters ( the main domain objects) are developed and play out the scenes (collaborations) in the play (the system) by speaking their lines (sending messages) and performing actions ( triggering behavior) appropriate to their roles. Each scene supports the plot and requires the appropriate behavior of the actors on stage. As plays are developed, scenes are added and sometimes characters and roles are added and lines change. This is a process similar to the kind of changes incorporated in OO development. As an application adds functions or is redesigned for maintainability, objects and scenarios the objects carry out are added and refined.

In many ways, design patterns are scenes with collaborating objects that may be brought "on stage" to help provide a solution to a design problem - i.e. beef up, jazz-up and possibly simplify the design to accommodate change and variability. Different types of design problems require different patterns. The design problems and what patterns to consider to "bring on stage" are listed in Table 2, Design Problem, Design Solution and Design Patterns, which is based on a discussion in the Gang of Four book [Gamma 95].

Design and implementation can often be accomplished together, especially with a high-level OO language like Smalltalk. When it comes time to implement the design, Smalltalk developers would be wise to adopt some of the patterns that Kent Beck has catalogued in his Smalltalk Best Practice Patterns book [Beck 96]. It covers patterns related to methods, messages, instance variables, temporary variables, collections, classes and formatting. One interesting thing to consider is how many of these patterns would also apply to Java. This book could be a starting point for a Java Best Practice Patterns book.

References:

[Alpert 97] Alpert, S.R., Brown, K., & B. Woolf, The Design Patterns Smalltalk Companion - to be published in 1997

[Beck 96] Beck, K., Smalltalk Best Practice Patterns, 1996, Prentice-Hall, ISBN 0-13-476904-X

[Fowler 96] Fowler, M., Analysis Patterns: Reusable Object Models, 1996, Addison-Wesley, ISBN 0-201-89542-0

[Gamma 95] Gamma, Erich, Helm, Richard, Johnson, Ralph, & Vlissides, John, 1995, Design Patterns: Elements of Reusable Object-Oriented Software, Reading, MA, Addison-Wesley.

Enjoy the article? Subscribe to Eye on Objects!

Bruce Whitenack is a Software Writer in Residence with The Object People, U.S. in Raleigh, North Carolina. He is the author of RAPPeL (Requirements Analysis Process Pattern Language) and co-author of Crossing Chasms as well as the course developer for VisualAge for Smalltalk Server: Transaction Managed Objects and TOPLink, a relational database to objects framework . He welcomes your comments..

Home Page