1. OO Methodology Elaboration Iteration 2 - Design Patterns -

2. 2 Table of Contents Iteration 2 Requirements GRASP: More Patterns for Assigning Responsibilities –Polymorphism –Pure Fabrication –Indirection –Protected Variations Designing Use-Case Realizations with GoF Design Patterns –Adapter –Factory –Strategy –Composite –Facade –Observer

3. 3 Iteration 2 Requirements Support for variations in third-party external services. Complex pricing rules Pluggable business rules A design to refresh a GUI window when the sale total changes

4. 4 Strategy Pattern NextGen POS –how to resolve complex pricing logic, such as a store-wide discount for the day, senior citizen discounts, etc. Strategy –Context many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors. you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms. an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures. a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class. –Solution Define each algorithm/policy/strategy in a separate class, with a common interface

5. 5 Strategy Pattern Structure

6. 6 Strategy Pattern Sale Pricing Strategies –the behavior of pricing varies by the strategy –each strategy has polymorphic method getTotal()

7. 7 Strategy Pattern Context Object –Sale object –Connected to a strategy object

8. 8 Strategy Pattern Context object needs attribute visibility to its strategy –to the interface, not a concrete class

9. 9 Strategy Pattern Creating a Strategy with a Factory –data-driven : dynamically change the pricing policy

10. 10 Strategy Pattern Consequences 1.Families of related algorithms 2.An alternative to subclassing You can subclass a Context class directly to give it different behaviors. It mixes the algorithm implementation with Context's, making Context harder to understand, maintain, and extend. you can't vary the algorithm dynamically. 3.Strategies eliminate conditional statements. 4.A choice of implementations. 5.Clients must be aware of different Strategies. 6.Communication overhead between Strategy and Context 7.Increased number of objects

11. 11 Strategy Pattern Example : Linebreaking Strategy in a Text Formatter

12. 12 Composite Pattern NextGen POS Requirements –How do we handle the case of multiple, conflicting pricing policies? 20% senior discount policy preferred customer discount of 15% off sales over $400 on Monday, there is $50 off purchases over $500 buy 1 case of Darjeeling tea, get 15% discount off of everything –One sale may have several pricing strategies conflict resolution strategy –best for the customer –best for the store pricing strategy categories –time period –customer type –a particular line item 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 also offer a design for the conflict resolution?

13. 13 Composite Pattern Composite –Context/Problem How to treat a group or composition structure of objects the same way as a non-composite object? –Solution Define classes for composite and atomic objects so that they implement the same interface

14. 14 Composite Pattern CompositePricingStrategy Class

15. 15 Composite Pattern Collaboration with a Composite –Sale does not know or care if its pricing strategy is an atomic or composite

16. 16 Composite Pattern Creating Multiple SalePricingStrategies –start by creating a Composite that contains the present moment’s store discount policy (e.g. PercentageDiscountPricingStrategy) –if at a later step in the scenario, another pricing strategy is discovered to also apply (e.g. Senior discount)

17. 17 Composite Pattern Customer Type Discount Use Case : Process Sale 5b. Customer says they are eligible for a discount 1. Cashier signals discount request 2. Cashier enters Customer identification 3. System presents discount total –Introducing the new system operation, enterCustomerForDiscount(custId)

18. 18 Composite Pattern enterCustomerForDiscount(custId) Design Issues –who creates a strategy (by Factory) –who requests Factory to create a strategy (Sale by Low coupling and Expert) –ID to Objects pattern(custID to Customer object) –Passing aggregate object as parameter

19. 19 Composite Pattern Consequences –defines class hierarchies consisting of primitive objects and composite objects. Wherever client code expects a primitive object, it can also take a composite object. –makes the client simple. Clients can treat composite structures and individual objects uniformly. –makes it easier to add new kinds of components. –can make your design overly general. The disadvantage of making it easy to add new components is that it makes it harder to restrict the components of a composite. Example

20. 20 Facade Pattern NextGen POS Requirements –Different customers who wish to purchase the NextGen POS would like to customize its behavior slightly (pluggable business rules) at predictable points in the scenarios, such as when makeNewSale or enterItem occurs in the ProcessSale use case, or when a cashier starts cashing in. –For example gift certificate rule charitable donation rules payment type of change dues –Analysis and Design the specific scenario points across all use cases must be identified (enterItem, chooseCashChange,...) low impact on the existing software components may want to experiment with different solutions

21. 21 Facade Pattern Context/Problem –A common, unified interface to a disparate set of implementations or interfaces – such as within a subsystem – required. –There may be undesirable coupling to many things in the subsystem, or the implementation of the subsystem may change Solution –Design a single point of contact to the subsystem – a facade object that wraps the subsystem. –The facade object presents a single unified interface Structure

22. 22 Facade Pattern Rule Engine Subsystem –responsible for evaluating a set of rules against an operation

23. 23 Facade Pattern Creating facade object and calling operations in facade object –Facades are often accessed via a singleton factory. –Calls to the facade should be placed near the start of the methods that have been defined as the points for pluggable rules public class Sale { public void makeLineItem (ProductSpecification spec, int quantity) { SalesLineItem sli = newSlaesLineItem(spec, quantity); if (POSRuleEngineFacade.getInstance().isInvalid(sli, this)) return;..... }... }

24. 24 Facade Pattern Programming Environment

25. 25 Observer Pattern NextGen POS

26. 26 Observer Pattern Observer (Publish-Subscribe) –Context/Problem Different kinds of subscriber objects are interested in the state changes or events of a publisher object, and want to react in their own unique way when the publisher generates an event. The publisher wants to maintain low coupling to the subscribers –Solution Define a subscriber or listener interface. Subscribers implement this interface. The publisher can dynamically register subscribers who are interested in an event. And notify them when an event occurs

27. 27 Observer Pattern Listener Interface

28. 28 Observer Pattern Subscribing Listener Objects Publishing an event(Sale total change)

29. 29 Observer Pattern Receiving event notification Alternative solution(callback)

30. 30 Observer Pattern Observer is not only for connecting UIs and model objects