1 / 139

Elemental Design Patterns

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

geneva
Download Presentation

Elemental Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Elemental Design Patterns Jason Smith The Software Revolution, Inc. based on UNC PhD work, and “Elemental Design Patterns”, Addison-Wesley, 2012

  2. Decorator (GOF)

  3. 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

  4. Decompose DecoratorObjectifier Zimmer, 1995

  5. 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

  6. Decompose DecoratorObject Recursion Woolf, 1998

  7. 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

  8. 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?

  9. 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?

  10. 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

  11. 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

  12. Pattern Descriptions Design Pattern A common solution to a common problem within a particular context Hard to fit: participants, collaborations

  13. 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

  14. 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?

  15. 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

  16. 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

  17. 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

  18. 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)

  19. FMOT Fields, Methods, Objects, Types OO entities we characterize relationships among

  20. FMOT Fields, Methods, Objects, Types Defines is a scope relationship

  21. OO Entity InteractionsFMOTNon-scoping

  22. Terminologymethod call o . f( ) calls p . g( ) enclosing object enclosing object Called method Calling method

  23. EDP Basicsin UML A B b: B g() h() f() b.g()

  24. EDP Basicsin Code class A { B b; f ( ) { b.g(); } } class B { g ( ) { } h ( ) { } } main ( ) { A a; a.f(); }

  25. More EDPsDeputized Redirection

  26. More EDPsRecursion

  27. First Four EDPs object similarity Recursion Conglomeration similar Redirection Delegation dissimilar method similarity dissimilar similar

  28. 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

  29. Another Example

  30. 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)

  31. 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.

  32. Decorator (GOF)

  33. Decorator in PIN

  34. Abstract Factory

  35. Factory Method

  36. Decorator

  37. Proxy

  38. Chain of Responsibility

  39. Template Method

  40. Create Object

  41. Retrieve

  42. Inheritance

  43. Abstract Interface

  44. Delegation

  45. Redirection

  46. Conglomeration

  47. Recursion

  48. Revert Method

  49. Extend Method

More Related