Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | herbert-ford |
View: | 215 times |
Download: | 0 times |
TALK OUTLINE
Pattern Definition GoF Patterns
GoF Patterns Classification Creational Patterns Structural Patterns Behavioral Patterns
Architectural Patterns Idioms
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.
TYPES OF PATTERNS
• Architectural Patterns• Design Patterns• Idioms
• …• E.g.: Usability Patterns• Anti-Patterns
THE SACRED ELEMENTS OF THE FAITH
FMFactory Method
107
PTPrototype
117
AFAbstract Factory
87
BUBuilder
97
SSingleton
127
CPComposite
163
PXProxy
207
AAdapter
139
DDecorator
175
FAFacade
185
BRBridge
151
The role structure
FLFlyweight
195
CRChain of
Responsibility
223
TMTemplateMethod
325
SRStrategy
315
CDCommand
233
MMMemento
283
MDMediator
273
STState
305
OObserver
293
ITIterator
257
INInterpreter
243
VVisitor
331
The role behaviors
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
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.
TEMPLATE METHOD
Intent: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine steps of an algorithm changing the algorithm’s structure.
TEMPLATE METHOD
Consequences: Template Method prove code reuse It lead to an inverted control structure: “the
Hollywood principle” that says “Don’t call us, we’ll call you.”
OBSERVER
Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
Also Know As: Dependents, Publish-Subscribe
Motivation: Maintain a consistency between objects in a system that is partitioned into a collection of cooperating classes.
ARCHITECTURAL PATTERNS
It expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.
LAYERS
It helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.
Example: Networking Protocols.
Context: A large system that requires decomposition.
LAYERS
Consequences: Reuse of layers Support for standardization Dependencies are kept local Exchangeability Cascades of changing behavior Lower efficiency Difficulty of establishing the correct granularity of
layers
MODEL-VIEW-CONTROLLER
It divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Example: A system for political elections with
many representations. Context: Interactive applications with a flexible human-computer interface
MODEL-VIEW-CONTROLLER
Consequences: Multiple views of the same model Synchronized views “Plugglable” views and controllers Increased complexity Potential for excessive number of updates Intimate connection between view and controller Close coupling of views and controller to a model
IDIOMS
Idioms are low-level patterns specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them with the features of the giver language.
Idioms provides a help to solve some recurring problem with a programming language. Ex. Memory management, object creation, naming of methods, source cod formatting and so on.
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.