GRASP: 더 많은 객체에 책임 할당

1. GRASP: 더 많은 객체에 책임 할당 Chapter 25 Applying UML and Patterns Craig Larman

2. Objectives • Learn to apply the following GRASP patterns: • Polymorphism • Pure Fabrication • Indirection • Protected Variations 금오공과대학 컴퓨터공학부 컴퓨터공학전공

3. Introduction • GRASP stands for General Responsibility Assignment Software Patterns. • It is a learning aid of fundamental principles by which responsibilities are assigned to objects and objects are designed. • We already learned about the first five GRASP patterns: • Information Expert, Creator, High Cohesion, Low Coupling, Controller 금오공과대학 컴퓨터공학부 컴퓨터공학전공

4. Introduction • In this presentation we will look at four new GRASP patterns: • Polymorphism • Indirection • Pure Fabrication • Protected Variations 금오공과대학 컴퓨터공학부 컴퓨터공학전공

5. 25.1 Polymorphism • Problem • Who is responsible when behaviors vary by type? • How to handle alternatives based on type? • If – then – else or case statements requires source code modification. • How to create pluggable software components? • Server replacement without affecting the client 금오공과대학 컴퓨터공학부 컴퓨터공학전공

6. Polymorphism • Solution • Polymorphism is a fundamental principle in designing how a system is organized to handle similar variations. • When related alternatives or behaviors vary by type (class), assign responsibility for the behavior-using polymorphic operations-to the types for which the behavior varies. • Do not use conditional logic to perform varying alternatives based on type • 이전에 사용하던 솔루션은? • if then else • #IFDEF ASGOODASTAX_TAX_CALC 금오공과대학 컴퓨터공학부 컴퓨터공학전공

7. UML Notation • UML Notation for Interfaces and Return types 금오공과대학 컴퓨터공학부 컴퓨터공학전공

8. Example • NextGen POS application supporting multiple Tax Calculators is a polymorphic operation. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

9. Discussion • Polymorphism is a fundamental principle in designing how a system is organized to handle similar variation. • Contraindications • Developers may indulge in speculative “future-proofing”against unknown possible variations. • Benefits • Extensions required for new variations are easy to add. • New implementation can be introduced without affecting clients. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

10. 26.2 Pure Fabrication • Problem • What object should have the responsibility, • when you do not want to violate High Cohesion and Low Coupling, or other goals, • but solutions offered by Information Expert are not appropriate? • There are many situations in which assigning responsibilities only to domain concepts leads to problems in terms of poor cohesion or coupling. • Solution • Assign a highly cohesive set of responsibilities to an artificial classthat does not represent a problem domain concept - something made up, in order to support high cohesion and low coupling and reuse. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

11. Pure Fabrication: Example • To save the Sale instances in a relational database. • By Information Expert, Sale class itself have the responsibility • But the above solution leads to: • Low Cohesion: database tasks are not related to the concept of sale. • High Coupling: The Sale class is coupled to the relational database interface. • Low Reusability: The general task of saving to the database may be needed by other classes. Assigning it to Sale class causes poor reuse and lots of duplication. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

12. Pure Fabrication: Example • Solution • Create a new class that is solely responsible for saving objects. • This class is a Pure Fabrication. • Ex. • The Sale remains well-designed, with high cohesion and low coupling. • The PersistentStorage class is itself relatively cohesive, having the sole purpose of storing or inserting objects in a persistent storage medium. • The PersistentStorage class is a very generic and reusable object. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

13. Discussion • Objects can be divided into • Representational decomposition • Software classes which is related to a thing in a domain • Ex. Sale, TableofContents • Behavioral decomposition • Responsibilities by grouping behaviors or by algorithm that is not related to a real-world domain concept • Ex. TableofContentsGenerator • Many existing OO design patterns are example of Pure Fabrications 금오공과대학 컴퓨터공학부 컴퓨터공학전공

14. Benefits • High Cohesion is supported • because that only focuses on a very specific responsibility are factored into a fine grained class set of related tasks. • Reuse potential may be increased • because of the presence of fine grained pure fabrication classes. • Contraindications • If overused, • Pure Fabrication could lead to too many behavior objects • If we overuse pure fabrication, symptom is that most of the data inside the objects is being passed to other objects. • Related patterns • Most of the GoF patterns are pure fabrication 금오공과대학 컴퓨터공학부 컴퓨터공학전공

15. 25.3 Indirection • Problem • Where to assign a responsibility, to avoid direct coupling between two or more things? • How to de-couple objects so that low coupling is supported and reuse potential remains higher? • Solution • Assign the responsibility to an intermediate object to mediate between other components so that they are not directly coupled. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

16. Indirection: Example • Tax Calculator Adapter • act as intermediaries to the external tax calculators. • By adding a level of indirection and adding polymorphism, • the adapter objects protect the inner design against variations in the external interfaces. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

17. Indirection: Example • Persistent Storage • The Pure Fabrication example • decoupling the Sale from the relational database services • A PersistentStorage class is also an example of Indirection. • The PersistentStorage acts as a intermediary between the Sale and the database. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

18. Discussion • Just as many existing design patterns are specializations of Pure Fabrication, many are also specializations of Indirection. • Adapter, Facade, and Observer are examples [GHJV95]. • Many Pure Fabrications are generated because of Indirection • The motivation for Indirection is usually Low Coupling • Benefit • Low Coupling between components. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

19. 25.4 Protected Variations • Problem • How to design objects, subsystems and systems so that the variations or instability in these elements does not have an undesirable impact on other elements? • Solution • Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them. • Example • External tax calculator problem and its solution with Polymorphism illustrate Protected Variations (Figure 22.1). • Using polymorphism with various ITaxCalculatorAdapter implementations, protection within the system from variations in external APIs is achieved. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

20. Discussion • was first published by Cockburn • Mechanisms Motivated by PV • PV is a root principle motivating most of the mechanisms to provide flexibility and protection from variations. • Later, one learns techniques such as • rule-based languages, rule interpreters, reflective and metadata designs, virtual machines, and so forth 금오공과대학 컴퓨터공학부 컴퓨터공학전공

21. Protected Variations: Mechanisms • Core Protected Variation • Data encapsulation, interfaces, polymorphism, indirection. • Data Driven Design • "parameterize" a system in some way at runtime. • Reading codes, class file paths, class name. • style sheets, metadata for object-relational mapping, reading windows layout, property file (registry) • Service Lookup • Clients are protected from variations in the location of services • JNDI, LDAP, Java’s Jini, UDDI. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

22. Protected Variations: Mechanisms • Interpreter-Driven Designs • rule interpreters that execute rules read from an external source. • Reflective or Meta-Level Designs • java.beansJntrospector • The system is protected from the impact of logic or external code variations by reflective algorithms that use introspection and meta-language services. • Uniform Access • Some languages ada, Eiffel, and C# support a syntactic construct so that both a method and field access are expressed the same way. class MyClass { private var x:Number; function MyClass () { } public function get x () : Number { return x; } public function set x (value:Number) { x = value; } } 금오공과대학 컴퓨터공학부 컴퓨터공학전공

23. The Liskov Substitution Principle (LSP) • Software methods that work with a class T should work with all subclasses of T. 8. Structure-Hiding Design • Don't Talk to Strangers! • Avoid creating designs that traverse long object structure paths and send messages (or talk) to distant, indirect (stranger) objects. • messages should only be sent to the following objects: 1. The this object (or self). 2. A parameter of the method. 3. An attribute of this. 4. An element of a collection which is an attribute of this. 5. An object created within the method. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

24. Example In new systems in early iteration, it is not stable 금오공과대학 컴퓨터공학부 컴퓨터공학전공

25. Protected Variations: Example • In the external tax calculator problem, the point of instability is the different interfaces to the external tax calculators. • By adding a level of indirection, an interface, and using polymorphism with various adaptors, protection within the system from variations in external calculator APIs is achieved. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

26. Protected Variations: Contraindications • Two change • Variation point: in the existing requirement • Evolution point: may arise in the future • The cost of “future-proofing” at evolution point may outweigh the cost incurred by a simple design that is reworked as necessary. • Example • Script and interpreter in a mobile environment 금오공과대학 컴퓨터공학부 컴퓨터공학전공

27. Benefits • Extensions required for new variations are easy to add. • New implementations can be introduced without affecting clients. • Coupling is lowered. • The impact or cost of changes be lowered. 금오공과대학 컴퓨터공학부 컴퓨터공학전공