copyright © 1995-2004 active frameworks inc. - all rights reserved - v2.0design pattern catalog -...

Copyright © 1995-2004 Active Frameworks Inc. - All Rights Reserved - V2.0 Design Pattern Catalog - Page L3-1

PS95&96-MEF-L10-1Dr. M.E. Fayad

Creational

Paradigm Shift, Inc.Software Factory

Behavioral

Structural

Lesson 3:Cataloging of Design Patterns

Lesson 3:Cataloging of Design Patterns

Object-Object-OrientedOriented

DesignDesign PatternPatternss



Lesson ObjectivesLesson Objectives

Show how to catalog each of the design patterns using a standard template or Gamma’s template .

Compare Gamma’s template with other template

Show how to select a Design Pattern

Show how to use a Design Pattern

Present cataloging assumptions

Objectives



Design Patterns Must be Documented in a Catalog

Patterns are

Everywhere!



Definition and Template

• Design Patterns are defined in terms of object-oriented concepts.

• Design Patterns are sufficiently abstract to avoid specifying implementation details, thereby ensuring wide applicability.

• But a pattern may provide hints about potential implementation issues.

• Each design pattern in the catalog is described using a standard template.

• Three major benefits of the template:

– Ensure uniformity between entries in the catalog

– Document each pattern in the appropriate level of details

– Help compare similar patterns



Design Pattern Template

Design Pattern’s Name Jurisdiction Characterization

Intent

Also Known As

Motivation

Applicability

Structure

Participants

Collaborations

Consequences

Implementation

Sample Code

Known Uses

Related Patterns

Observer



• Pattern Name and Classification– The pattern’s name conveys the essence of the pattern succinctly

– A good name is vital because it will become part of the design vocabulary.

• Intent: a short statement that answers the following questions:– What does the design pattern do?

– What is its rationale and intent?

– What particular design issue or problem does it address?

• Also Known As– Other well-known names for the pattern, if any.

Design Pattern Template (cont’d)



• Motivation– A scenario that illustrates a design problem and how the class &

object structures in the pattern solve the problem.

• Applicability– What are the situations in which the design pattern can be applied?

– What are examples of poor designs that the pattern can address?

– How can you recognize these situations?

• Structure– A graphical representation of the classes in the pattern using a

notation based on the Object Modeling Technique (OMT) [Rumbaugh 92] and Booch notations [Booch 94].

– We also use Interaction diagram [Jacobson 92 & Booch 94] to illustrate sequences of requests and collaborations between objects




• Participants– Classes and objects and their responsibilities

• Collaborations– How the participants collaborate to carry out their responsibilities.

• Consequences– How does pattern support its objectives?

– What are the trade-offs and results of using the pattern?

– What aspect of system structure does it let you vary independently?

• Implementation– What pitfalls, hints, or technique should you be aware of when

implementing the pattern?

– Are there language-specific issues?




• Sample code– Code fragments that illustrate how you can implement

the pattern in C++ or smalltalk

• Known Uses– Examples of the pattern found in real systems

• Related Patterns– What design patterns are closely related to this one?

– What are the important differences?

– With which other patterns should this one be used?




• Frank Bushmann added three extra fields to the Gamma’s template:

• Dynamic Behavior– The dynamic behavior of a pattern is illustrated

• Methodology– The methodology (steps) for constructing a pattern is listed

• Variants– Possible variants of the pattern are listed and described




Common Causes of Reuse Errors in OO Software & Design Patterns

Particular implementation class when creating an object

Particular operations

Operating environment

Specific Representation or implementation

Particular algorithms

Particular clients and inter-object relationships

Subclassing as an extension mechanism.

Dependence on:



How to Select a Design Pattern

Consider how design patterns

solve design problems

Scan intent sections

Study how patterns interrelate

Study patterns of like purpose

Examine the cause of redesign

Consider what should be variable

in your design



How to Use a Design Pattern

Identify the classes in the application which will be constructed by introducing the design pattern

Identify the classes in the pattern

Select meaningful names for these classes in the context of the application

Define the classes, establish their inheritance relationships, and define their instance variables

Define application-specific names for operations in the pattern

Implement the operations to carry out the responsibilities and collaborations in the pattern



Design Patterns Classification is Based on Two Orthogonal Criteria

• First classification criterion reflects what a pattern does:

– Creational patterns concern the process of object creation

– Structural patterns deal with the composition of classes or objects

– Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibilities

• Second classification criterion reflects to what object-oriented concepts the pattern is applied:

– Class patterns deal with relationships between base classes and their subclasses; class patterns cover static semantics

– Object patterns concern relationships between peer objects

– Compound patterns deal with recursive object structures



Design Pattern Space

Character- ization

Jurisdiction

Class Factory Method Adaptor (c) Template Method Bridge (c)

Creational Structural Behavioral

Object Abstract Factory Adaptor (o) Chain of Responsibility Prototype Bridge (o) Command Solitaire Facade Iterator (o)

Flyweight Mediator Proxy Memento

Observer Strategy

Compound Builder Composite Interpreter Decorator Iterator (cc)

Walker



Creational Patterns

• The Creational Class Patterns defer some part of object creation to subclasses.

• The Creational Object Patterns abstract how sets of objects are created.

• The Creational Compound Patterns are concerned with the creation of recursive object structures.



Structural Patterns

• The Structural Class Patterns use inheritance to compose protocols or code.

• The Structural Object Patterns describe ways to assemble objects to realize new functionality.

• The Structural Compound Patterns capture techniques for structuring recursive object structures.



Behavioral Patterns

• The Behavioral Class Patterns capture how classes cooperate with their subclasses to fulfill their semantics.

• The Behavioral Object Patterns describe how a group of peer objects cooperate to perform a task that no single object can carry out alone.

• The Behavioral Compound Patterns deal with behavior in recursive object structures.



Classification Scheme

This is another classification scheme that is introduced by Frank Buschmann. The classification scheme consists of three categories of design issue:

1. Granularity

2. Functionality

3. Structural principles



Granularity

• There are three levels of granularity:

1. Architectural Frameworks– represent fundamental principles for structuring software

systems into subsystems and the relationships between them.

2. Design Patterns– describe basic schemes for structuring subsystems and

components of software architecture, as well as their relationships.

3. Idioms– describe how to implement particular components (parts) of

subsystem and component functionality, or their relationships to other components within a given design.



Functionality

Four categories :

1. Creation of objects– Patterns may specify how to create particular instances of

complex recursive or aggregate object structures

2. Guiding communication between objects– Patterns may describe how to organize the communication

between a set of collaborating objects

3. Access to objects– Patterns may describe how to access the services and state of

shared or remote objects in a safe way, without violating their encapsulation of state and behavior

4. Organizing the computation of complex functions– Patterns may specify how to distribute responsibilities among

cooperating objects to solve a more complex function or task



Structural Principles

Four categories :

1. Abstraction– A pattern provides an abstract or generalized view of particular (often

complex) entity or task in a software system

2. Encapsulation– A pattern encapsulates details of a particular object, component, and

services to remote dependency on the pattern from its clients or to protect these details from access.

3. Separation of concerns– A pattern factors out specific responsibilities into separate objects to

solve a particular task.

4. Coupling and cohesion– A pattern removes or relaxes the structural and communication

relationships and dependencies between strongly coupled objects

copyright © 1995-2004 active frameworks inc. - all rights reserved - v2.0design pattern catalog -...

Documents