ADAPTER FAÇADE FACTORY OBSERVER SINGLETON STRATEGY Design Patterns

What is a pattern? A design pattern describes a problem that occurs over and over in software engineering and then describes the solution in a sufficiently generic manner as to be applicable in a wide variety of contexts.

Typical pattern format The pattern name The problem Specification of Explanation why it is important Applications Examples of known uses The solution A description of classes possibly with a structure diagram A language independent implementation, with language-specific issues as appropriate Sample code Consequences Results Trade-offs of using the pattern A discussion of related patterns

ADAPTER

Wrapping Objects to Unify Interfaces Question: What pattern wraps objects to give them new functionality? Now we wrap objects with a different purpose: To make their interfaces look like something they are not To simplify the interfaces of objects

Adapters Real world is full of them! Object oriented adapters Some examples? Object oriented adapters Scenario: you have an existing software system that you need to work a new vendor library into, but the new vendor designed their interfaces differently than the last vendor. What to do? Write a class that adapts the new vendor interface into the one you’re expecting. Your Existing System Vendor Class Their interface doesn’t match the one you’ve written your code against. Not going to work! The adapter implements the interface your classes expect And talks to the vendor interface to service your requests Your Existing System Vendor Class == Adapter Your Existing System Vendor Class Adapter No code changes No code changes New code

If it walks like a duck….. If it walks like a duck and quacks like a duck, then it might be a duck turkey wrapped with a duck adapter…. public interface Duck { public void quack (); public void fly (); } public class MallardDuck implements Duck { public void quack () { System.out.println(“Quack”); public void fly ( ) { System.out.println (“I am flying”); Meet the fowl! public interface Turkey { public void gobble (); public void fly ( ); } public class WildTurkey implements Turkey { public void gobble ( ) { System.out.println(“Gobble Gobble”); public void fly ( ){ System.out.println(“I’m flying a short distance”); Concrete implementations are similar -- just print out the actions.

Now…. Lets say you are short on Duck objects and would like to use some Turkey objects in their place. Can’t use them outright because they have a different interface. public class TurkeyAdapter implements Duck { Turkey turkey; public TurkeyAdapter (Turkey turkey) { this.turkey = turkey; } public void quack ( ) { turkey.gobble ( ); public void fly ( ){ for (int j = 0; j<5; j++) turkey.fly ( ); First, you need to implement the interface of the type you are adapting to. This is the interface your client expects. Next, we need to get a reference to the object that we are adapting; here we do that through the constructor. Now we need to implement all the methods in the interface; the quack() translation between classes is easy; just call the gobble method. Even though both interfaces have a fly ( ) method, Turkeys fly in short spurts -- they can’t do long distance flying like ducks. To map between a Duck’s fly ( ) method and a Turkey’s we need to call the Turkey’s fly ( ) method five times to make up for it.

The Adapter Pattern Defined The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. <<Interface>> Target request ( ) Client The Adapter implements the target interface The client sees only the Target interface. Full of good OO design principles: --Use of object composition --Pattern binds the client to an interface and not an implementation Adapter request ( ) Adaptee specificRequest () Adapter is composed with the Adaptee All requests get delegated to the Adaptee

Object and Class Adapters There are two types of Adapters Object Adapter : what we have seen so far. Class Adapter: not as common as it uses multiple inheritance, which isn’t possible in Java. <<Interface>> Target request ( ) Adaptee specificRequest () Client Difference: The only difference is that with class adapter we subclass the Target and the Adaptee, while the object adapter uses composition to pass requests to an adaptee. Adapter request ( ) Question: Object Adapters and Class Adapters use two different means of adapting the adaptee (composition versus inheritance). How do these implementations affect the flexibility of the adapter?

Real World Adapters Old world Enumerators New world Iterators Enumeration has a simple interface. <<interface>> Enumeration hasMoreElements ( ) nextElement ( ) Tells whether there are any more elements in the collection. Old world Enumerators New world Iterators And today…legacy code that exposes the Enumerator interface. Yet we want new code to use Iterators. Need an adapter. Returns the next element <<interface>> Iterator hasNext ( ) next ( ) remove ( ) Tells you if you have looked at all the elements Gets the next one Removes an item from the collection

Summary When you need to use an existing class and its interface is not the one you need, use an adapter. An adapter changes an interface into one a client expects. Implementing an adapter may require little work or a great deal of work depending on the size and complexity of the target interface. There are two forms of adapter patterns: object and class adapters. Class adapters require multiple inheritance. An adapter wraps an object to change its interface, a decorator wraps an object to add new behaviors and responsibilities.

FAÇADE

OVERVIEW When you need to simplify and unify a large interface or a complex set of interfaces, use a façade. A façade decouples the client from a complex subsystem. Implementing a façade requires that we compose the façade with its subsystem and use delegation to perform the work of the façade. You can implement more than one façade for a subsystem. A façade “wraps” a set of objects to simplify!

Façade Another pattern that wraps objects! For a different reason - to simplify the interface Aptly named as this pattern hides all the complexity of one or more classes behind a clean, well-lit façade!

Home Sweet Home Theater Building your own home theater - check out the components that you have/need to put together. That’s a lot of classes, a lot of interactions, and a big set of interfaces to learn and use. Amplifier tuner dvdPlayer cdPlayer on () off ( ) setCD( ) setDVD ( ) setStereoSound ( ) setSurroundSound ( ) setTuner ( ) setVolume ( ) DvdPlayer amplifier on () off ( ) eject ( ) pause ( ) play ( ) setSurroundAudio ( ) setTwoChannelAudio ( ) stop ( ) Tuner amplifier on () off ( ) setAM ( ) setFM ( ) setFrequency ( ) Screen up () down ( ) TheaterLights on ( ) off ( ) dim ( ) Projector dvdPlayer on () off ( ) tvMode ( ) wideScreenMode ( ) CdPlayer amplifier on () off ( ) eject ( ) pause ( ) play ( ) stop ( ) PopcornPopper on ( ) off ( ) pop ( )

Lights, Camera, Façade! HomeTheaterFacade watchMovie () endMovie () listenToCD ( ) endCD () listenToRadio () endRadio ( ) (1) Create a Façade for the HomeTheater which exposes a few simple methods such as watchMovie ( ) (2) The Façade treats the home theater components as its subsystem, and calls on the subsystem to implement its watchMovie ( ) method. (4) The Façade still leaves the subsystem accessible to be used directly. (3) The Client now calls methods on the façade and not on the subsystem. Amplifier tuner dvdPlayer cdPlayer on () off ( ) setCD( ) setDVD ( ) setStereoSound ( ) setSurroundSound ( ) setTuner ( ) setVolume ( ) DvdPlayer amplifier on () off ( ) eject ( ) pause ( ) play ( ) setSurroundAudio ( ) setTwoChannelAudio ( ) stop ( ) Tuner amplifier on () off ( ) setAM ( ) setFM ( ) setFrequency ( ) Screen up () down ( ) TheaterLights on ( ) off ( ) dim ( ) The subsystem the façade is simplifying. Projector dvdPlayer on () off ( ) tvMode ( ) wideScreenMode ( ) CdPlayer amplifier on () off ( ) eject ( ) pause ( ) play ( ) stop ( ) PopcornPopper on ( ) off ( ) pop ( )

The Façade Defined The Façade Pattern provides a unified interface to a set of interfaces in a subsytem. Façade defines a higher-level interface that makes the subsystem easier to use. Unified interface that is easier to use. Happy client whose job just became easier because of the façade. Client Facade More complex subsystem

Summary When you need to simplify and unify a large interface or a complex set of interfaces, use a façade. A façade decouples the client from a complex subsystem. Implementing a façade requires that we compose the façade with its subsystem and use delegation to perform the work of the façade. You can implement more than one façade for a subsystem. A façade “wraps” a set of objects to simplify!

BREAK FOR 10 MINS 

FACTORY

What can you do? Principle: Identify the aspects that vary and separate them from what stays the same. How might you take all the parts of your application that instantiate concrete classes and separate or encapsulate them from the rest of your application?

Identifying aspects that Vary Own a pizza store in cutting edge Objectville! Pizza orderPizza ( ) { Pizza pizza = new Pizza ( ); pizza.prepare () ; pizza.bake (); pizza.cut (); pizza.box (); return pizza; } For flexibility it would be nice if this wasn’t concrete, but we can’t instantiate abstract classes!

Identifying Aspects that Vary (2/ But you need more than one type of pizza: Pizza orderPizza ( String type) { Pizza pizza; if (type.equals (“cheese”) { pizza = new CheesePizza (); } else if (type.equals(“greek”)) { pizza = new GreekPizza ( ); } else if (type.equals(“pepperoni”) { pizza = new PepperoniPizza ( ); } pizza.prepare () ; pizza.bake (); pizza.cut (); pizza.box (); return pizza; Pass in the type of Pizza to orderPizza( ) Instantiate based on type of pizza Prepare the pizza

But the pressure is on to add more pizza types…. Need to add a couple trendy pizzas to their menu: Clam and Veggie. Greek is not selling so well - so take it out! What do you think would need to vary and what would stay constant?

Modified orderPizza ( ) Pizza orderPizza ( String type) { Pizza pizza; if (type.equals (“cheese”) { pizza = new CheesePizza (); } else if (type.equals(“greek”)) { pizza = new GreekPizza ( ); } else if (type.equals(“veggie”)) { pizza = new VeggiePizza ( ); } else if (type.equals(“pepperoni”) { pizza = new PepperoniPizza ( ); } pizza.prepare () ; pizza.bake (); pizza.cut (); pizza.box (); return pizza; This code is not closed for modification! This is what varies This is what we expect will stay the same

Encapsulating Object Creation Move the object creation out of the orderPizza ( ) method. How? Move the creation code into a special purpose object that is concerned with only creating pizzas if (type.equals (“cheese”) { pizza = new CheesePizza (); } else if (type.equals(“greek”)) { pizza = new GreekPizza ( ); } else if (type.equals(“veggie”)) { pizza = new VeggiePizza ( ); } else if (type.equals(“pepperoni”) { pizza = new PepperoniPizza ( ); } Pizza orderPizza ( String type) { Pizza pizza; pizza.prepare () ; pizza.bake (); pizza.cut (); pizza.box (); return pizza; } Pull it out What’s going to go here? We place this code into a separate object SimplePizzaFactory

Building a Simple Pizza Factory Factories handle the details of the object creation. public class SimplePizzaFactory { public Pizza createPizza (String type ) { Pizza pizza = null; if (type.equals (“cheese”) ) { pizza = new CheesePizza (); } else if (type.equals(“greek”)) { pizza = new GreekPizza ( ); } else if (type.equals(“veggie”)) { pizza = new VeggiePizza ( ); } else if (type.equals(“pepperoni”) { pizza = new PepperoniPizza ( ); } Here’s code we plucked out of the orderPizza() method. Code is still parameterized by the type of pizza, just like the original code. Could this method be made static?

Reworking the PizzaStore class public class PizzaStore { SimplePizzaFactory factory; public PizzaStore(SimplePizzaFactory factory) { this.factory = factory; } public Pizza orderPizza (String type){ Pizza pizza; pizza = factory.createPizza (type); pizza.prepare () ; pizza.bake (); pizza.cut (); pizza.box ( ); return pizza; PizzaStore has a reference to the factory PizzaStore gets the factory passed in the constructor New operator replaced by create method!

Why is this better? SimplePizzaFactory may have many more clients than orderPizza ( ) method PizzaShopMenu, HomeDelivery etc. Client code does not have any concrete classes anymore!! SimpleFactory is not really a design pattern but the actual Factory patterns are based on it!

Simple Factory Pattern This is the factory where we create pizzas; this should be the only part of our application that refers to concrete Pizza classes. Product of the factory (abstract) Pizza PizzaStore SimplePizzaFactory createPizza () createPizza () prepare( ) bake ( ) cut ( ) box ( ) create method sometimes declared static. Client of the factory. Goes through factory to get instances of Pizza CheesePizza PepperoniPizza Abstract class with some helpful implementations that can be overridden. VegiePizza ClamPizza Concrete products. Each product needs to implement the Pizza interface.

Summary All factories encapsulate object creation Simple factory, while not a bona fide design pattern, is a simple way to decouple your clients from concrete classes. Factory method relies on inheritance: object creation is delegated to subclasses which implement the factory method to create objects Abstract Factory relies on object composition: object creation is implemented in methods exposed in the factory interface. All factory methods promote loose coupling by reducing the dependency of your application on concrete classes. The intent of Factory method is to allow a class to defer instantiation to its subclasses. The intent of the Abstract Factory is to create families of related objects without having to depend on their concrete classes. The Dependency Inversion principle guides us to avoid dependencies on concrete types and to strive for abstractions. Factories are a powerful technique for coding to abstractions, not concrete classes.

How important is it to use Factories? Factories are powerful tools Great benefit when trying to conform to DIP Heuristics for use: Strict interpretation -- use factories for every volatile class But don’t use factories for everything: too extreme Initially - don’t start out using factories, add them in as you see the need for them Might need to “spoof” objects during testing Remember: Factories are a complexity that can often be avoided in the early phases They unnecessarily complicate designs!

THAT’S ALL FOR TODAY 

OBSERVER

The Weather-O-Rama! Weather-O-Rama provides What we implement Current conditions is one of three different displays. The user can also get weather stats and a forecast. Pulls data Displays Humidity Sensor Device Current Conditions Temp: 72 Humidity: 60 Pressure: Temperature Sensor Device Weather Station Display Device Pressure Sensor Device Weather-O-Rama provides What we implement The Job: Create an app that uses the WeatherData object to update three displays for current conditions, weather stats, and a forecast.

The WeatherData class /* WeatherData getTemperature ( ) These three methods return the most recent weather measurements for temperature, humidity, and pressure respectively. We don’t care HOW these variables are set; the WeatherData object knows how to get updated information from the Weather Station WeatherData getTemperature ( ) getHumidity ( ) getPressure ( ) measurementChanged ( ) // other methods /* * This method gets called whenever the * measurements have been updated. * / public void measurementsChanged ( ){ // Your code goes here } A clue: what we need to add!

The Specs so far The WeatherData class has getter methods for three measurement values: temperature, humidity, and pressure. The measurementsChanged ( ) method is called anytime new weather measurement data is available. (We don’t know or care how this method is called; we just know that it is) We need to implement three display elements that use the weather data: a current conditions display, a statistics display, and a forecast display. These displays must be updated each time WeatherData has new measurements. The system must be expandable -- other developers can create new custom display elements and users can add or remove as many display elements as they want to the application.

A First Misguided Attempt at the Weather Station public class WeatherData { // instance variable declarations public void measurementsChanged ( ) { float temp = getTemperature ( ); float humidity = getHumidity ( ); float pressure = getPressure ( ); currentConditionsDisplay.update (temp, humidity, pressure); statisticsDisplay.update (temp, humidity, pressure); forecastDisplay.update (temp, humidity, pressure); } // other WeatherData methods here Grab the most recent measurements by calling the WeatherData’s getter methods (already implemented) Now update the displays. Call each display element to update its display, passing it the most recent measurements.

What’s wrong with the first implementation? public class WeatherData { // instance variable declarations public void measurementsChanged ( ) { float temp = getTemperature ( ); float humidity = getHumidity ( ); float pressure = getPressure ( ); currentConditionsDisplay.update (temp, humidity, pressure); statisticsDisplay.update (temp, humidity, pressure); forecastDisplay.update (temp, humidity, pressure); } // other WeatherData methods here Area of change, we need to encapsulate this. By coding to concrete implementations we have no way to add or remove other display elements without making changes to the program. At least we seem to be using a common interface to talk to the display elements…they all have an update ( ) method that takes temp, humidity and pressure values.

Time for the Observer! The Newspaper or Magazine subscription model: A newspaper publisher goes into business and begins publishing newspapers You subscribe to a particular newspaper, and every time there is a new edition, its gets delivered to you. As long as you remain a subscriber, you get new newspapers. You unsubscribe when you don’t want the newspapers anymore -- and they stop being delivered While the publisher remains in business people, hotels, airlines etc constantly subscribe and unsubscribe to the newspaper.

The Observer Pattern Defined The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically. One to many relationship (Subject can have many observers) Object that holds state int 2 Subject Object Dog Object Cat Object Mouse Object Observer Objects Dependent objects (observers are dependent on the subject to update them when data changes.) Automatic update/notification

Observer Class Diagram Here’s the Subject interface. Objects use this interface to register as observers and also to remove themselves from being observers. All potential observers need to implement the Observer interface. This interface has just one method, update ( ), that gets called when the Subject’s state changes. Each subject can have many observers The concrete subject may also have methods for setting and getting its state. A concrete subject always implements the Subject interface. In addition to the register (attach) and remove (detach) methods, the concrete subject implements a notify() method to notify observers whenever state changes. Concrete observers can be any class that implements the Observer interface. Each observer registers with a concrete subject to receive updates.

Summary OO Principle in play: Strive for loosely coupled designs between objects that interact. Main points: The Observer pattern defines a one to many relationship between objects Subjects (observables), update Observers using a common interface Observers are loosely coupled in that the Observable knows nothing about them, other than they implement the Observer interface.

Summary (cntd.) Main points (cntd.): You can push or pull data from the Observable when using the pattern (“pull” is considered more correct) Don’t depend on a specific order of notification for your Observers Don’t be afraid to create our own version of the Observable if needed

BREAK FOR 10 MINS 

SINGLETON

What is this? Singleton: How to instantiate just one object - one and only one! Why? Many objects we need only one of: thread pools, caches, dialog boxes, objects that handle preferences and registry settings etc. If more than one instantiated: Incorrect program behavior, overuse of resources, inconsistent results Alternatives: Use a global variable Downside: assign an object to a global variable then that object might be created when application begins. If application never ends up using it and object is resource intensive --> waste! Use a static variable Downside: how do you prevent creation of more than one class object?

Singleton Pattern Defined The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it. The getInstance ( ) method is static, which means it is a class method, so you can conveniently access this method anywhere in your code using Singleton.getInstance ( ). That’s just as easy as accessing a global variable, but we get benefits like lazy instantiation from the Singleton. The uniqueInstance class variable holds our one and only one instance of Singleton. Singleton static uniqueInstance // other useful variables static getInstance ( ) // other methods A class implementing a Singleton Pattern is more than a Singleton; it is a general purpose class with its own set of data and methods.

Summary The Singleton Pattern ensures you have at most one instance of a class in your application The Singleton Pattern also provides a global access point to that instance. Java’s implementation of the Singleton Pattern makes use of a private constructor, a static method combined with a static variable Examine your performance and resource constraints and carefully choose an appropriate Singleton implementation for multi-threaded applications.

STRATEGY

The Strategy Design Pattern The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithms vary independently from the clients that use it. Defines the generic interface Context ContextInterface ( ) Strategy AlgorithmInterface ( ) Context manages the data structures that a concrete strategy operates on. ConcreteStrategyA AlgorithmInterface ( ) ConcreteStrategyB AlgorithmInterface ( ) ConcreteStrategyC AlgorithmInterface ( ) ConcreteStrategy classes provide the implementations of the different strategies. These operate on the data structures in the the Context, and can be set dynamically.

Summary Strategy pattern allows selection of one of several algorithms dynamically. Algorithms may be related via an inheritance hierarchy or unrelated [must implement the same interface] Strategies don’t hide everything -- client code is typically aware that there are a number of strategies and has some criteria to choose among them -- shifts the algorithm decision to the client.

THAT’S ALL FOR THE CHAPTER 