d esign p atterns weslei a. de t. marinho. t alk o utline pattern definition grasp patterns gof...
Post on 03-Jan-2016
Embed Size (px)
DESIGN PATTERNSWeslei A. de T. Marinho
TALK OUTLINEPattern DefinitionGRASP PatternsGoF PatternsGoF Patterns ClassificationCreational PatternsStructural 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 principlesPatterns 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 PATTERNSGRASP PatternsArchitectural PatternsDesign PatternsIdioms
E.g.: Usability PatternsAnti-Patterns
BASIC PATTERN METAMODELProblemSolutionConsequencePatternname*
GOF PATTERN METAMODELPatternnameclassificationIntentMotivation(ExampleScenario)Applicability(Problem)**Structure(SolutionGraphicalDescription)*BehavioralStructure(Collaboration)StaticStructureClassDiagramObjectDiagramParticipant*Issues*ImplementationIssueConsequenceSampleCode*ExampleDomain**relPatternsA.K.A
GRASP PATTERNSGRASP stands for General Responsibility Assignment Software Pattern
Will be presented the following GRASP Patterns:Information ExpertCreatorLow CouplingHigh Cohesion
CREATORB is a creator of A objects.If more than one option applies, usually prefer a class B which aggregates or contains class A.
Name: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.
CREATOR WHO CREATES THE SQUARE?
INFORMATION EXPERTProblem: Who knows about a Square object, given a key?
Name:Information ExpertProblem: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.
INFORMATION EXPERTHow to distribute the responsibilities for obtain the sales total?
LOW COUPLINGGiven 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.
Name:Low CouplingProblem:How to reduce the impact of change?Solution: (advice)Assign responsibilities so that (unnecessary) coupling remains low. Use this principle to evaluate alternatives.
Name:High CohesionProblem: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 COHESIONLow cohesion implies on code:Hard to comprehendHard to reuseHard to maintainDelicate; constantly affected by changeIn 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 CreationalStructural BehavioralScopeClassFactory Method Adapter InterpreterTemplate Method ObjectAbstract FactoryAdapterChain of ResponsibilityBuilderBridgeCommandPrototypeCompositeIteratorSingletonDecoratorMediatorFacadeMementoProxyFlyweightObserverStateStrategyVisitor
ABSTRACT FACTORYIntent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.Also Knows As: Kit
ABSTRACT FACTORY - MOTIVATION
ABSTRACT FACTORY - STRUCTURE
BUILDERIntent: Separate the construction of a complex object from its representation so that the same construction process can create different representations.
SIGLETONIntent: Ensure a class only has one instance, and provide a global point of access to it.
FACADEIntent: 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.
BIBLIOGRAPHYFreeman, E., Sierra, K., Bates, B. 2004. Head First Design Patterns. OReilly 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.