Design Pattern Detection

1. Design Pattern Detection

2. Design Patterns • A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution • Good designers know not to solve every problem from first principles • They reuse solutions • This is very different from code reuse • Software practitioners have not done a good job of recording experience in software design for others to use COSC6431

3. Design Patterns – 2 • Definition • “We propose design patterns as a new mechanism for expressing object oriented design experience. Design patterns identify, name and abstract common themes in object oriented design. They capture the intent behind a design by identifying objects, collaborations and distribution of responsibilities.” • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ,“Design Patterns”, Addison-Wesley, 1995. ISBN 0-201-63361-2 COSC6431

4. Others On Design Patterns • Christopher Alexander • “Each person describes a problem which occurs over and 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.” • Cunningham • “Patterns are the recurring solutions to the problem of design. People learn patterns by seeing them and recall them when need be without a lot of effort” COSC6431

5. Others On Design Patterns – 2 • Booch • “A pattern is a solution to a problem in a specific context. A pattern codifies specific knowledge collected from experience in a domain.” COSC6431

6. Patterns & Frameworks • Patterns support reuse of software architecture and design • They capture static and dynamic structures of successful solutions to problems. These problems arise when building applications in a particular domain • Frameworks support reuse of detailed design and program source text • A framework is an integrated set of components that collaborate to provide a reusable architecture for a family of related applications COSC6431

7. Patterns & Frameworks – 2 • Frameworks tend to be less abstract than patterns • Together, design patterns and frameworks help to improve key quality factors like reusability, extensibility and modularity COSC6431

8. Design Problems • Finding appropriate classes • Determine class granularity • how abstract, how correct • Specify interfaces • Specify implementation • Put reuse to work • Client vs inheritance • Relate run time and compile time structures • program text may not reflect design COSC6431

9. Design Problems – 2 • Design for change is difficult • Common problems • Explicit object creation • Dependence of particular operations • avoid hard coded operations • Dependencies on hardware or software platforms • Dependencies of object representation • Dependencies on algorithms • Tight coupling COSC6431

10. Claims of the Pattern Community • Well defined design principles have a positive impact on software engineering • Achievable reusability • Provide common vocabulary for designers • communicate, document, explore alternatives • Patterns are like micro architectures • Useful for building small parts of a system • Reduce the learning time for understanding class libraries • Avoid redesign stages by using encapsulated experience COSC6431

11. When to Use Patterns • Solutions to problems that recur with variations • No need for pattern if the problem occurs in only one context • Solutions that require several steps • Not all problems need all steps • Patterns can be overkill if solution is a simple linear set of interactions • Solutions where the solver is more interested in “does there exist a solution?” than in a solution’s complete derivation • Patterns often leave out lots of detail COSC6431

12. Pattern Benefits • Enable large scale reuse of software architectures • Explicitly capture expert knowledge and design trade-offs • Help improve developer communication • Help ease the transition to OO methods COSC6431

13. Pattern Drawbacks • Patterns do not lead to direct code reuse • Patterns are often deceptively simple • You may suffer from pattern overload • Patterns must be validated by experience and debate rather than automated testing • Integrating patterns into a process is human intensive rather than a technical activity COSC6431

14. General Template • Name • Intent • What does the pattern do? What problems does it address? • Motivation • A scenario of pattern applicability • Applicability • In which situations can this pattern be applied • Participants • Describe participating classes/objects COSC6431

15. General Template – 2 • Collaborations • How do the participants carry out their responsibilities? • Diagram • Graphical representation of the pattern • Consequences • How does the pattern support its objectives? • Implementation • Pitfalls, language specific issues • Examples • From real systems COSC6431

16. Classification • Structural • Deal with decoupling interface and implementation of classes and objects • Adapter, Facade, Decorator • Behavioural • Deal with dynamic interaction among collections of classes and objects • Visitor, Iterator, Master-Slave • Creational • Deal with initializing and configuring collections of classes and objects • Prototype, Abstract Factory, Builder COSC6431

17. Adapter Pattern • Intent • Convert the interface of a class into another interface that the client expects. • Lets classes work together that couldn't otherwise • Motivation – Applicability • Reuse of classes • class is not reusable because its interface does not match the domain-specific interface • If a class with a different, or incompatible, interface is expected, we do not want to change the reusable classes to suit the new application COSC6431

18. Adapter – Example • EDITOR expects a SHAPE • TEXT_VIEW is not a SHAPE • TEXT is a SHAPE • Features are mapped (body calls relevant method) to TEXT_VIEW SHAPE EDITOR FIGURE TEXT TEXT_VIEW COSC6431

19. Adapter – Applicability • Want to use an existing class but its interface does not match the one you need • Want to create a reusable class that cooperates with unrelated or unforeseen classes with incompatible interfaces COSC6431

20. Facade Pattern • Intent • Provide a common interface to a set of interfaces within a subsystem • Defines a higher level interface that should make the subsystem easier to use • Motivation • Structuring a system into subsystems reduces complexity • A common design goal is to minimize communication between subsystems COSC6431

21. Facade – Diagram Clients Facade Subsystem classes COSC6431

22. Facade – Applicability • Want to provide a simple interface to a collection of complex subsystems • Provide a simple default view • As systems grow, classes become smaller more refined • Better for reuse • More difficult for clients to use COSC6431

23. Facade – Applicability – 2 • Decouple subsystems from clients • Reduce implementation dependencies • Layer your subsystems • Each layer has a single entry point • Layers communicate only through Facade interface COSC6431

24. Facade – Participants, Example • Facade • Compiler • Knows which subsystem classes are responsible for a request • Delegates client requests to appropriate subsystem objects • Subsystems • Scanner, Parser, Code Generator etc. • Implement system functionality • Handle work assigned by Facade object • Have no knowledge of the facade • Keep no references to it COSC6431

25. Facade – Collaborations • Clients communicate with the subsystem by sending requests to Facade • Facade forwards requests to subsystem • Facade may have to translate its interface to subsystem interface (use Adapter) • Clients that use facade don't have direct access to the subsystems COSC6431

26. Facade – Consequences • Benefits • Shields clients from subsystem components • Reducing number of objects clients deal with • Promotes weak coupling between subsystems and clients • Can vary components of subsystem without affecting clients • Doesn't prevent expert clients from direct access to subsystems • Choice between ease of use and generality COSC6431

27. Decorator Pattern • Intent • Attach additional responsibilities to an object dynamically. • Provide a flexible alternative to subclassing for extending functionality COSC6431

28. Decorator – Motivation • Motivation – Applicability • Want to add responsibility to individual objects not to entire classes • Add properties like border, scrolling, etc to any user interface component as needed • Enclose object within a decorator object for flexibility • Nest recursively for unlimited customization COSC6431

29. Decorator – Example • Compose a border decorator with a scroll decorator for text view. a_border_decorator component a_scroll_decorator component a_text_view COSC6431

30. Decorator – Example Diagram VISUAL_COMPONENT * draw * DECORATOR * TEXT_VIEW + draw component : VISUAL_ COMPONENT BORDER_DECORATOR + SCROLL_DECORATOR + draw border_width draw_border draw scroll_position scroll_to COSC6431

31. Decorator – Applicability • Add responsibilities to individual objects dynamically and transparently • Without affecting other objects • For responsibilities that can be withdrawn • When subclass extension is impractical • Sometimes a large number of independent extensions are possible • Avoid combinatorial explosion • Class definition may be hidden or otherwise unavailable for subclassing COSC6431

32. Decorator – General Structure COMPONENT * method * CONCRETE_COMPONENT + DECORATOR * component : COMPONENT method CONCRETE_DECORATOR_B + CONCRETE_DECORATOR_ A + method another_feature method other_feature COSC6431

33. Decorator – Participants • Component • defines the interface for objects that can have responsibilities added to them dynamically • Concrete component • Defines an object to which additional responsibilities can be attached • Decorator • Maintains a reference to a component object and defines an interface that conforms to COMPONENT • Concrete decorator • Add responsibilities to the component COSC6431

34. Decorator – Consequences • Benefits • More flexibility than static inheritance • Can add and remove responsibilities dynamically • Can handle combinatorial explosion of possibilities • Avoids feature laden classes high up in the hierarchy • Pay as you go when adding responsibilities • Can support unforeseen features • Decorators are independent of the classes they decorate • Functionality is composed in simple pieces COSC6431

35. Decorator – Consequences – 2 • Liabilities • From object identity point of view, a decorated component is not identical • Decorator acts as a transparent enclosure • Cannot rely on object identity when using decorators • Lots of little objects • Often result in systems composed of many look alike objects • Differ in the way they are interconnected, not in class or value of variables • Can be difficult to learn and debug COSC6431

36. Iterator Pattern • Intent • Access elements of a container sequentially without exposing the underlying representation • Motivation • Be able to process all the elements in a container • Different iterators can give different sequential ordering • Binary tree • preorder, inorder, postorder • Do not need to extend container interface COSC6431

37. Iterator – Structure Diagram ITERATOR * CONTAINER + next * allDone * item * size add remove CONCRETE_ITERATOR + make_1 make_2 next allDone item COSC6431

38. Iterator – Applicability • Access a container’s contents without knowing about or using its internal representation • Support multiple traversals • Provide a uniform interface for traversing a container’s contents • Support polymorphic iteration COSC6431

39. Iterator – Participants • Iterator • Defines the interface for accessing and traversing a container’s contents • Concrete iterator • Implements the iterator interface • Keeps track of the current position in the traversal • Container • Could provide a method to create an instance of an iterator COSC6431

40. Iterator – Consequences • Supports variations in the traversal of a container • Complex containers can be traversed in different ways • Trees and graphs • Easy to change traversal order • Replace iterator instance with a different one • Iterators simplify the container interface • Do not need iterator interface in container interface • Multiple simultaneous traversals • Each iterator keeps track of its own state COSC6431

41. Visitor Pattern • Intent • Represent an operation to be performed on the components of an object structure • Define new operations on the structure without changing classes representing the components COSC6431

42. Prototype Pattern • Intent • Specify the kinds of objects to create using a prototypical instance and create new objects by copying this prototype COSC6431

43. Prototype – Motivation • Build an editor for musical scores by customizing a general framework for graphical editors • Add new objects for notes, rests, staves • Have a palette of tools • Click on eighth note tool and add it to the document • Assume Framework provides • Abstract_Graphic class • Abstract_Tool class for defining tools • Graphic_Tool subclass for creating instances of graphical objects and adding them to the document COSC6431

44. Prototype – Motivation – 2 • But Graphic_Tool doesn't know how to create instances of music classes • Could subclass Graphic_Tool for each kind of music object • But have lots of classes with insignificant variations • Solution is to copy or clone an instance called a prototype • Graphic_Tool is parameterized by the prototype to clone COSC6431

45. GRAPHIC * ROTATE_ TOOL + GRAPHIC_ TOOL + draw * clone * manipulate manipulate STAFF + NOTE * draw clone TOOL * manipulate * HALF + WHOLE + draw clone draw clone Prototype – Example COSC6431

46. Prototype – Structure PROTOTYPE * CLIENT + clone * operation CONCRETE_2 + CONCRETE_1 + clone clone COSC6431

47. Prototype – Participants • Prototype • Declares an interface for cloning itself • Concrete prototype • Implements an operation for cloning itself • Client • Creates a new object by asking a prototype to clone itself • Collaboration • Client • Asks a prototype to clone itself COSC6431

48. Detecting design patterns • A difficult task • Patterns are primarily a literary form • No rigorous mathematical definitions • Automatic detection beyond the state of the art of Artificial Intelligence • Instead, detect the artifacts of implementing the solution of the design pattern COSC6431

49. Detecting design patterns • Purely structural patterns are easier to detect • Purely behavioural patterns are much harder • Most patterns are somewhere in the middle COSC6431

50. Template solution • A template solution needs to be both: • Distinctive • The design diagram is not likely to be represented in a design that does not use the pattern • Unambiguous • Can only be done in one way (or in a small number of variants) COSC6431