TALK OUTLINE
Pattern Definition GRASP Patterns GoF Patterns
GoF Patterns Classification Creational Patterns Structural Patterns
WHAT IS A PATTERN?
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice“ (Christopher Alexander)
WHAT IS A PATTERN?
“Pattern is a named and well-known problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and discussion of its trade-offs, implementations, variations, and so forth.” (Craig Larman)
WHY USE PATTERNS?
• A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it.
• Patterns document existing, well-proven design experience.
• Patterns identify and specify abstractions that are above the level of single classes and instances, or of components.
• Patterns provide a common vocabulary and understanding for design principles
• Patterns are a means of documenting software architectures.
WHY USE PATTERNS?
Patterns support the construction of software with defined properties.
Patterns help you build complex and heterogeneous software architectures.
Patterns help you to manage software complexity.
TYPES OF PATTERNS
• GRASP Patterns• Architectural Patterns• Design Patterns• Idioms
• …• E.g.: Usability Patterns• Anti-Patterns
GOF PATTERN METAMODEL
Pattern
name
classification
Intent
Motivation(ExampleScenario)
Applicability(Problem)
*
*
Structure(SolutionGraphicalDescription
)
*
BehavioralStructure(Collaboration)
StaticStructure
ClassDiagram
ObjectDiagram
Participant*
Issues*
ImplementationIssue
Consequence
SampleCode
*
ExampleDomain *
*
relPatterns
A.K.A
GRASP PATTERNS
• GRASP stands for General Responsibility Assignment Software Pattern
• Will be presented the following GRASP Patterns:– Information Expert– Creator– Low Coupling– High Cohesion
CREATORName: Creator Problem: Who creates an A?Solution: (this can be viewed as advice)
Assign class B the responsibility to create an instance of class A if one of these is true (the more the better):
•B "contains" or compositely aggregates A.•B records A.•B closely uses A.•B has the initializing data for A.
B is a creator of A objects.If more than one option applies, usually prefer a class B which aggregates or contains class A.
INFORMATION EXPERTName: Information Expert
Problem: What is a basic principle by which to assign responsibilities to objects?
Solution: (advice) Assign a responsibility to the class that has the information needed to fulfill it.
Problem: Who knows about a Square object, given a key?
LOW COUPLINGName: Low Coupling
Problem: How to reduce the impact of change?
Solution: (advice) Assign responsibilities so that (unnecessary) coupling remains low. Use this principle to evaluate alternatives.
Given following classes:
What is better for a makePayment design?
A:
B:
In practice, the level of coupling alone can't be considered in isolation from other principles such as Expert and High Cohesion. Nevertheless, it is one factor to consider in improving a design.
HIGH COHESIONName: High Cohesion
Problem: How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?
Solution: (advice) Assign responsibilities so that cohesion remains high. Use this to evaluate alternatives.
HIGH COHESION
Low cohesion implies on code:• Hard to comprehend• Hard to reuse• Hard to maintain• Delicate; constantly affected by change
In practice, the level of cohesion alone can't be considered in isolation from other responsibilities and other principles such as Expert and Low Coupling.
GOF PATTERNS CLASSIFICATION
Table 1: Design pattern space
Purpose Creational Structural Behavioral
Scope Class Factory Method Adapter InterpreterTemplate Method
Object Abstract Factory Adapter Chain of Responsibility
Builder Bridge Command
Prototype Composite Iterator
Singleton Decorator Mediator
Facade Memento
Proxy Flyweight
Observer
State
Strategy
Visitor
ABSTRACT FACTORY
Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Also Knows As: Kit
BUILDER
Intent: Separate the construction of a complex object from its representation so that the same construction process can create different representations.
FACADE
Intent: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
BIBLIOGRAPHY Freeman, E., Sierra, K., Bates, B. 2004. Head First
Design Patterns. O’Reilly Media, Inc. Gamma, E., Helm, R., Johnson, R., Vlissides, J. 1995.
Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley Pub Co.
Larman, C. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition. Pearson Education, Inc.
Schmidt, D., Stal, M., Rohnert, H., Buschmann, F. 1996. PATTERN-ORIENTED SOFTWARE ARCHITECTURE VOLUME 1: A System of Patterns. John Wiley & Sons Ltd.