Chapter 26 Applying Gang of Four Design Patterns

Chapter 26 Applying Gang of Four Design Patterns CS 6359 Fall 2012 John Cole 1

The “Gang of Four” • The book was Design Patterns by Gamma, Helm, Johnson, and Vlissades CS 6359 Fall 2012 John Cole 2

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. CS 6359 Fall 2012 John Cole 3

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. CS 6359 Fall 2012 John Cole 4

Adapter related to: • Façade CS 6359 Fall 2012 John Cole 5

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. CS 6359 Fall 2012 John Cole 6

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 CS 6359 Fall 2012 John Cole 7

Factory • For example, a Factory can create a Tax. Adapter based upon knowledge of which tax module is being used. The program just calls the Factory’s method and gets an Adapter. CS 6359 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. CS 6359 Fall 2012 John Cole 9

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 CS 6359 Fall 2012 John Cole 10

Singleton • Singleton has a get. Instance 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 CS 6359 Fall 2012 John Cole 11

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. CS 6359 Fall 2012 John Cole 12

Strategy • In the POS system, pricing can be complex and rule-based. For example, there may be a taxfree day, a senior citizen discount, $10 off if the sale is over $200, etc. CS 6359 Fall 2012 John Cole 13

Strategy • Create multiple Sale. Pricing. Strategy classes with a polymorphic get. Total 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 CS 6359 Fall 2012 John Cole 14

Strategy • Since pricing strategies change over time, use a Pricing. Strategy. Factory to create them. • It can read a parameter from an external source and create the appropriate class. CS 6359 Fall 2012 John Cole 15

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 CS 6359 Fall 2012 John Cole 16

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 CS 6359 Fall 2012 John Cole 17

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: Composite. Best. For. Customer. Pricing. Strategy implements i. Sales. Pricing. Strategy CS 6359 Fall 2012 John Cole 18

Composite • Attach any object that implements ISale. Pricing. Strategy that has a get. Total method to the Sale object and it won’t know the difference CS 6359 Fall 2012 John Cole 19

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? CS 6359 Fall 2012 John Cole 20

GRASP and Composite • IDs to objects • Pass aggregate object as parameter CS 6359 Fall 2012 John Cole 21

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. CS 6359 Fall 2012 John Cole 22

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 CS 6359 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. CS 6359 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 CS 6359 Fall 2012 John Cole 25

Observer • An interface is defined; in this case, Property. Listener with the operation on. Property. Event. • Define the window to implement the interface. Sale. Frame 1 will implement the method on. Property. Event. • When the Sale. Frame 1 window is initialized, pass it the Sale instance from which it is displaying the total. CS 6359 Fall 2012 John Cole 26

Observer • The Sale. Frame 1 window registers or subscribes to the Sale instance for notification of "property events, “ via the add. Property. Listener message • Note that the Sale does not know about Sale. Frame 1 objects; rather, it only knows about objects that implement the Property. Listener 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 Property. Listeners, notifying each. CS 6359 Fall 2012 John Cole 27