Applying GOF Design Patterns

1. Applying GOF Design Patterns Chapter 26 Applying UML and Patterns Craig Larman Presented By : Naga Venkata Neelam

2. Objectives • Apply GRASP and GOF design patterns to the design of NextGen case study.

3. Introduction • The following GOF design patterns are explored in the subsequent sections : • Adapter • Analysis • Factory • Singleton • Strategy • Composite

4. Adapter(GOF) • Context/problem • How to resolve incompatible interfaces or provide a stable interface to similar components with different interfaces? • Solution • Convert the original interface of a component into another interface through an intermediate adapter object.

5. The Adapter Pattern • Adapters use interfaces and polymorphism to add a level of indirections to varying APIs in other components.

6. Using An Adapter

7. Using An Adapter • Protected Variations, Low Coupling, Polymorphism,Indirection helps us to view through the myriad details and see the essential alphabet of design techiques being applied. • Naming Convention has the advantage of easily communicating to others reading the code or diagrams what design patterns are being used.

8. Analysis Discoveries During Design:Domain Model • In addition to being a newly created software class in the Design Model, this is a domain concept. • The following figure illustrates the updated Domain Model.

9. Updated Partial Domain Model

10. Note • The architecture of the Design Model will usually be organized into layers.One of these layers of design classes will be called “Domain layer”. • It will contain software classes whose names and structure take inspiration from the domain vocabulary and concepts.

11. Factory(GOF) • Context/Problem • Who should be responsible for creating objects when there are special considerations, such as complex logic,a desire to separate the creation responsibilities for better cohesion, and so forth • Solution • Create a Pure Fabrication object called a Factory that handles the creation

12. Solution(2) • Showing a pseudo code allows one to include dynamic algorithm details on a static class diagram such that it may lessen the need for interaction diagrams.

13. Advantages of Factory Objects • Separate the responsibility of complex creation into cohesive helper objects. • Hide potentially complex creation logic • Allow introduction of performance-enhancing memory management strategies,such as object caching or recycling.

14. Singleton(GOF) • The Factory raises a new problem in the design: • Who creates the factory itself? • How is it accessed? • One solution is pass the Factory instance around as a parameter to wherever a visibility need is discovered for it, or to initialize the objects that need visibility to it,with a permanent reference. • Alternative is Singleton pattern.

15. Solution • Define a static method of the class that returns the singleton. • With this approach, a developer has global visibility to this single instance,via the static getInstance method of the class.

16. Visibility to Single Instance public class Register { public void initialize() {… do some work… //accessing the singleton Factory via the getInstance call AccountingAdapter = ServiceFactory.getInstance().getAccountingAdapter(); …do some work…} //other methods…}

17. Lazy Initialization public static synchronized ServiceFactory getInstance() { if(instance==null) { //critical section if multithreaded application instance = new ServicesFactory(); } return instance }

18. Eager Initialization public class ServiceFactory { //eager initialization private static ServicesFactory instnace = new ServicesFactory(); public static servicesFactory getInstance() { Return instance; } //other methods… }

19. Reasons to prefer lazy Initialization • Creation work is avoided, if the instance is never actually accessed. • The getInstance lazy initialization sometimes contains complex and conditional creation logic.

20. Implicit getInstance Singleton Pattern Message

21. Preferred Methods • Instance-side methods permit subclassing and refinement of the singleton class into subclasses. • Most object-oriented remote communication mechanisms only support remote-enabling of instance methods,not static methods. • A class is not always a singleton in all application contexts.

22. Conclusion of External services with varying Interfaces Problem

23. Strategy(GOF) • Context/Problem • How to design for varying, but related,algorithms or policies? • How to design for the ability to change these algorithms or policies • Solution • Define each algorithm/policy/strategy in a separate class, with a common interface

24. Strategy In Collaboration • A strategy object is attached to a context object- the object to which it applies the algorithm. • In this example the context object is a sale.

25. Creating a strategy with a factory • There are different pricing algorithms or strategies, and they change over time. • Who should create the strategy? • A straight forward approach is to apply the Factory pattern again: a PricingstrategyFactory can be responsible for creating all strategies needed by the application.

26. Context objects needs attribute visibility to its strategy • The reference in the sale will be declared in terms of the interface,not a class, so that any implementation of the interface can be bound to the attribute. • It is not desirable to cache the created strategy instance in a field of the PricingstrategyFactory, but rather to re-create one each time,by reading the external property for its class name, and then instantiating the strategy.

27. Factory for Strategies

28. Creating a Strategy

29. Creating a Strategy(2) • Protected Variations with respect to dynamically changing pricing policies has been achieved with the Strategy and Factory patterns. • Strategy builds on Polymorphism and interfaces to allow pluggable algorithms in an object design.

30. Composite(GOF) and other Design Principles • Context/Problem • How to treat a group or composition of objects the same way(polymorphically) as a non-composite(atomic object)? • Solution • Define classes for composite and atomic objects so that they implement the same interface.

31. Understanding composite (GOF) with an example • Suppose a store has the following policies in effect for a particular day: • 20% senior discount policy. • Preferred customer discount of 15% off sales over $400. • On day,there is $50 off purchases over $500. • Buy 1 case of Darjeeling tea, get 15% discount off of everything.

32. Problem • Suppose a senior who is also a preferred customer buys 1 case of Darjeeling tea, and $600 of veggieburgers. • What pricing policy should be applied?

33. Solution using conflict resolution strategy • In this strategy a store applies the following: • Best for the customer (lowest price) • Highest pricing strategy (during a difficult financial period)

34. Multiple Co-Existing Strategies • One sale may have several pricing strategies • Pricing strategy can be related to the type of customer • Pricing strategy can be related to the type of product being brought

35. Multiple co-existing strategies(2) • The ProductSpecification must be known by the StrategyFactory at the time of creation of a pricing strategy influenced by the product. • Is there a way to change the design so that the Sale object does not know if it is dealing with one or many pricing strategies, and offer a design for the conflict resolution? • And the answer is yes,with the composite pattern.

36. Signature feature of Composite Object • In composite pattern,the composite classes such as CompositeBestForCustomerPricingStrategy inherit an attribute pricingStratagies that contains a list of more ISalePricingStrategy objects. • The outer composite objects contains a list of inner objects, and both the outer and inner objects implement the same interface.

37. Collaboration with a Composite • In this the Sale does not know or care if its pricing strategy is an atomic object or a composite strategy that is it looks the same to the Sale object.

38. Object Code for CompositePricing Strategy //Super class so all subclasses can inherit a List of startegies public abstract class CompositePricingStrategy implements ISalePricingStrategy { protected List pricingStrategies = new ArrayList(); public add(ISalePricingStrategy s){ pricingStrategies.add(s);} public abstract Money getTotal(Sale sale); } // end of class

39. Object Code for CompositePricing Strategy (2) // a composite Strategy that returns the lowest total // of its inner SalePricingStrategies public class CompositeBestForCustomerPricingStrategy extends CompositePricingStrategy { public Money getTotal(Sale sale){ Money lowestTotal = new Money(Integer.MAX_VALUE); //iterate over all the inner strategies

40. Object Code for CompositePricing Strategy (3) for(Iterator i= pricingStrategies.iterator(); i.hasNext();){ ISalePricingStrategy strategy = (ISalePricingStrategy)i.next(); Money total = strategy.getTotal(sale); lowestTotal = total.min(lowestTotal); } return lowestTotal; } }//end of class

41. Inheritance in UML

42. Creating Multiple SalePricingStrategies • There are three points in the scenario where pricing strategies may be added to the composite: • Current store-defined discount,added when the sale is created. • Customer type discount,added when the customer type is communicated to the POS. • Product type discount added when the product is entered to the sale.

43. Creating a composite strategy for the first case.

44. Creating a Process sale for the second case • Use case UCI: Process Sale • Extensions (or Alternative Flows) Customer says they are eligible for a discount (e.g employee, preferred customer) • Cashier signals discount request. • Cashier enters Customer identification • System presents discount total, based on discount rules.

45. Creating a pricing strategy for a customer discount

46. Creating a pricing strategy for a customer discount(2)

47. Considering GRASP and Other principles in the Design • An ID is given to the customer • Transform the customer ID to a Customer object. • Pass aggregate Object as Parameter.

48. Note • Although this application of composite was to a strategy family, the Composite pattern can be applied to other kinds of objects • For example, it is common to create "macro commands " - commands that contain other commands -through the use of Composite.

49. Note(2) • Composite is often used with the Strategy and Command Patterns. • Composite is based on Polymorphism and provides Protected Variations to a client so that it is not impacted if its related objects are atomic or composite.

50. Facade(GOF) • Context/Problem • A common, unified interface to a disparate set of implementations or interfaces- such as within a subsystem-is required.There may be undesirable coupling to many things in the subsystem, or the implementation of the subsystem may change.What to do?