Download
1 / 139
1.4k likes | 1.58k Views
Elemental Design Patterns. J ason Smith The Software Revolution, Inc . b ased on UNC PhD work, and “Elemental Design Patterns”, Addison-Wesley, 2012. Decorator (GOF). Decorator informally. Used to extend behavior dynamically, at run time
E N D
Elemental Design Patterns Jason Smith The Software Revolution, Inc. based on UNC PhD work, and “Elemental Design Patterns”, Addison-Wesley, 2012
Decorator informally • Used to extend behavior dynamically, at run time • Like an internal plug-in system as found in a web browser • Alternative to using inheritance to provide all possible combinations of behaviors
Decompose DecoratorObjectifier Zimmer, 1995
Objectifier • Allows a single object interface to represent multiple concrete implementations • Client requests a method to be invoked via the objectifier interface • Client cannot know which of the concrete method bodies will execute and provide the service
Decompose DecoratorObject Recursion Woolf, 1998
Object Recursion • Chains two objects with related types • Object recursion uses Objectifier as the backbone of its form… • Adds a link between one of the concrete implementations and the interface • Uses the link to invoke the same method --to “recurse” in a sense, but on a different (related) object
Turtles all the way down • So Decorator can be described in terms of composing smaller pieces • Are these pieces as small as they can be? • Perhaps there is more “downward” to go • Where is the bottom of this abstraction pile?
Turtles all the way down • So Decorator can be described in terms of composing smaller pieces • Are these pieces as small as they can be? • Perhaps there is more “downward” to go • Where is the bottom of this abstraction pile?
Turtles all the way down • So Decorator can be described in terms of composing smaller pieces • Are these pieces as small as they can be? • Perhaps there is more “downward” to go • Where is the bottom of this abstraction pile? EDP
Turtles all the way down decorator • So Decorator can be described in terms of composing smaller pieces • Are these pieces as small as they can be? • Perhaps there is more “downward” to go • Where is the bottom of this abstraction pile? object recursion objectifier EDP Elemental design patterns
Pattern Descriptions Design Pattern A common solution to a common problem within a particular context Hard to fit: participants, collaborations
Relationships • Participants, Collaborations are parts and relationships • Relationships form the core of design • Design of a car is more than a piles of pieces… engine, tires, transmission, seats • Design shows how the parts relate… connect, interact, work of one affects function of another • Parts list gives components • Relationships tell how parts function in concert to win over the entropy of the pile
Relationships • What is smallest relationship we can define? • A single concept connection between two things • Look for such among the entities in OO programming • Means we have to decide… what are the conceptual entities in OO programs?
Pause… for directions • Goal: detect elemental relationships automatically, if we can • Goal: compose elemental patterns to get higher patterns (automatically, if we can) • Higher pattern means more complex, harder to find patterns
Contextual Relationships • Different relationships, different purposes • Scoping relationships give context • Scope is how an element is made unique among all other elements in the system class Menu in package GUI_Elements is not the same thing as class Menu in package Restaurant_Items • Scope: an enclosing something that has a name, in which you define something new
Context: Scope • Class: scope for methods and fields it defines • Package/namespace: scope for all in it • Method/function: scope for local variables • Access an element: specify the scopes from outer level in • Implicit notation: No scope for locals in a method, or another method in same class • Differing notation: GUI_Element::Menu vs.aMenu.anItem
Relationships… what else? • We now have scope relationships… what else can we form relationships between? • Classes, their fields and methods…. not much else • What about objects? Different from classes? • Classes do two things • Type information… member methods and fields that will exists separately in each object created • Global shared fields… “static” class methods and fields • Class is really a type with an object (for global)
FMOT Fields, Methods, Objects, Types OO entities we characterize relationships among
FMOT Fields, Methods, Objects, Types Defines is a scope relationship
Terminologymethod call o . f( ) calls p . g( ) enclosing object enclosing object Called method Calling method
EDP Basicsin UML A B b: B g() h() f() b.g()
EDP Basicsin Code class A { B b; f ( ) { b.g(); } } class B { g ( ) { } h ( ) { } } main ( ) { A a; a.f(); }
First Four EDPs object similarity Recursion Conglomeration similar Redirection Delegation dissimilar method similarity dissimilar similar
Theoretical Foundations • s-calculus • Abadi and Cardelli, “A Theory of Objects”, 1998 • Computation model for OO programs • Object form of l-calculus • r-calculus • Modification and extension for patterns • Operators for reliances • J. Smith, 2004
Reliances • Focus on OO programming concepts, not OO language constructs • a.f() calls b.g(), then b.g() calls c.h() • We can see that a.f() does not call c.h() (a structural relationship) • However a.f() relies on c.h() to execute correctly in order for f to complete its work • So there is a reliance between a.f() and c.h() (conceptual, not structural)
References • Zimmer, W. Relationships between design patterns. In J.O. Coplien and D.C. Schmidt, eds., Pattern Languages of Program Design. Addison-Wesley, Voston, 1995, pp. 345-364. • Woolf, B. The object recursion pattern. In N. Harrison, B. Foote, and H. Rohnert, eds., Pattern Languages of Program Design 4. Addison-Wesley, Boston, 1998, pp. 41-52.
