Chapter 26 Applying Gang of Four Design Patterns 1CS6359 Fall 2012 John Cole.

Chapter 26

Applying Gang of Four Design Patterns

1CS6359 Fall 2012 John Cole

The “Gang of Four”

• The book was Design Patterns by Gamma, Helm, Johnson, and Vlissades

2CS6359 Fall 2012 John Cole

Pattern Overload

• As of 2000, there were over 500 published design patterns. Therefore, we’ll also be looking at how the following patterns are related to simpler ones and at underlying principles.

3CS6359 Fall 2012 John Cole

Adapter

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

4CS6359 Fall 2012 John Cole

Adapter related to:

• Façade

5CS6359 Fall 2012 John Cole

Factory

• Problem: Who should be responsible for creating objects when there are special considerations, such as complex creation 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.

6CS6359 Fall 2012 John Cole

Factory

• Maintain a separation of concerns in your programs. That is, modularize or separate concepts so that each has high cohesion

• Using a domain object to create adapters does not support high cohesion

• Hides complex logic and may allow caching or other memory-use efficiencies

7CS6359 Fall 2012 John Cole

Factory

• For example, a Factory can create a TaxAdapter based upon knowledge of which tax module is being used. The program just calls the Factory’s method and gets an Adapter.

CS6359 Fall 2012 John Cole 8

Singleton

• Problem: Exactly one instance of a class is allowed: it is a "singleton." Objects need a global and single point of access.

• Solution: Define a static method of the class that returns the singleton.

9CS6359 Fall 2012 John Cole

Singleton

• The Factory pattern raises the issue of who creates it and how it is accessed

• We need only one instance of the Factory, whose methods are called from various places in the code

• One solution is to pass the Factory object as a parameter, but this can be messy

• In the UML class diagram, use a “1” in the upper right to indicate creation of 1 instance

10CS6359 Fall 2012 John Cole

Singleton

• Singleton has a getInstance method that is static and returns an instance of itself if one does not exist.

• Wrap this in concurrency control• Reasons not to make all methods static:

cannot subclass; remote methods interface doesn’t support static; class may not always be a singleton in all contexts

11CS6359 Fall 2012 John Cole

Strategy

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

12CS6359 Fall 2012 John Cole

Strategy

• In the POS system, pricing can be complex and rule-based. For example, there may be a tax-free day, a senior citizen discount, $10 off if the sale is over $200, etc.

13CS6359 Fall 2012 John Cole

Strategy

• Create multiple SalePricingStrategy classes with a polymorphic getTotal method.

• This takes a Sale object and applies the discounting rule for its class.

• A Strategy object is attached to a context object, to which it applies its algorithm

14CS6359 Fall 2012 John Cole

Strategy

• Since pricing strategies change over time, use a PricingStrategyFactory to create them.

• It can read a parameter from an external source and create the appropriate class.

15CS6359 Fall 2012 John Cole

Composite

• Problem: How to treat a group or composition structure 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.

• The outer composite object contains a list of inner objects, and both inner and outer implement the same interface

16CS6359 Fall 2012 John Cole

Composite

• Pricing rules can be complex and conflicting. For example, on Monday this is in effect:

• 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

17CS6359 Fall 2012 John Cole

Composite

• Suppose a senior buys $600 worth of veggieburgers and a case of Darjeeling tea

• Store must have a conflict resolution strategy, usually “Best for the customer.”

• Composite class: CompositeBestForCustomerPricingStrategy implements iSalesPricingStrategy

18CS6359 Fall 2012 John Cole

Composite

• Attach any object that implements ISalePricingStrategy that has a getTotal method to the Sale object and it won’t know the difference

19CS6359 Fall 2012 John Cole

Composite

• How to create the strategies?• Design has a composite with the basic pricing

strategy. Then:– Store-defined discount, perhaps initially 0– Customer type discount– Product type discount– Two for one– Any others?

20CS6359 Fall 2012 John Cole

GRASP and Composite

• IDs to objects• Pass aggregate object as parameter

21CS6359 Fall 2012 John Cole

Façade• 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?

• Solution: Define a single point of contact to the subsystem: a Facade object that wraps the subsystem. This facade object presents a single unified interface and is responsible for collaborating with the subsystem components.

22CS6359 Fall 2012 John Cole

Façade

• This is similar to Adapter. It provides a single interface to what may be disparate subsystems. This provides a single point of entry

• Pluggable business rules, for example• Gives you a way to do low coupling

CS6359 Fall 2012 John Cole 23

Observer (Publish-Subscribe)• 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. Publisher wants to maintain low coupling to the subscribers.

• Solution: Define a "subscriber" or "listener" interface which Subscribers implement. The publisher can dynamically register subscribers who are interested in an event and notify them when an event occurs.

CS6359 Fall 2012 John Cole 24

Observer

• For example, when the total amount of a sale changes, the total displayed on the screen should change. You could just send a message from the domain object to the UI object

• This would violate Model-View separation

CS6359 Fall 2012 John Cole 25

Observer

• An interface is defined; in this case, PropertyListener with the operation onPropertyEvent.

• Define the window to implement the interface. SaleFrame1 will implement the method onPropertyEvent.

• When the SaleFrame1 window is initialized, pass it the Sale instance from which it is displaying the total.

CS6359 Fall 2012 John Cole 26

Observer

• The SaleFrame1 window registers or subscribes to the Sale instance for notification of "property events,“ via the addPropertyListener message

• Note that the Sale does not know about SaleFrame1 objects; rather, it only knows about objects that implement the PropertyListener interface. This lowers the coupling of the Sale to the window. The coupling is only to an interface, not to a GUI class.

• The Sale instance is thus a publisher of "property events." When the total changes, it iterates across all subscribing PropertyListeners, notifying each.

CS6359 Fall 2012 John Cole 27