170 likes | 293 Views
The Adapter Pattern. Scenario : An Existing System (your client code) interfaces to a Vendor Class library you purchased and incorporated into an application your company is currently selling. Existing System. Vendor1 Class. Vendor1 interface.
E N D
The Adapter Pattern SE-2811 Dr. Mark L. Hornick
Scenario: An Existing System (your client code) interfaces to a Vendor Class library you purchased and incorporated into an application your company is currently selling Existing System Vendor1 Class Vendor1 interface The Vendor goes out of business; what do you do???
The original configuration The ClientApp is writtensuch that it is heavily dependenton the functionality implementedin ServiceProvider, and is loadedwith calls to various ServiceProvidermethods. ServiceProvider may implementnumerous methods in a real situation;not only the few methods shown here SE-2811 Dr. Mark L. Hornick
Adapter (Wrapper) Pattern Existing System Vendor2 Class • Adapter • Implements the interface your classes expect • And talks to the vendor interface to service your requests. Existing System Vendor2 Class Adapter
The Adapter configuration 2. An interface declaring the same methodsas the original ServiceProvider is created 3. A replacement classfor the original ServiceProvider is found that providessimilar functionality,but with a differentset of methods: the adaptee 4. An adapter class is writtenwhich maps calls from the original methods to the new methods 1. The original ServiceProvider class is obsolete and discarded
The Adapter Pattern features • The client makes a request to the adapter by calling a method on it by continuing to program to the interface that mimics the methods of the original class. • The adapter translates the request into one or more calls on the adaptee • The amount of code is usually small, but may be complex due to indirect mappings from the original methods to the new methods. • The adapter transforms data or results from the adaptee into the form expected by the client • The client receives the results of the call and doesn’t care that there is an adapter doing the translation. • The only change to the client is that it must create an instance of the adapter rather than the original vendor class.
Cases to use Adapter • Legacy code exists that interfaces to a class library that has changed • Revision change • Vendor change • New application is being developed that will have to interface to a class library that has yet to be defined • Define an interface and write the adapter later SE-2811 Dr. Mark L. Hornick
The Façade Pattern SE-2811 Dr. Mark L. Hornick
Watching a Movie... • Interacting with the following classes: • Receiver/Amplifier • TV/Monitor • DVD Use multiple interfaces (remotes) to Turn on Receiver/amplifier Turn on TV/Monitor Turn on DVD player Set the Receiver input to DVD Put the Monitor in HDMI input mode Set the Receiver volume to medium Set Receiver to DTS Surround Start the DVD player.
To decrease the complexity.. We can create a new class TheaterFacade (e.g. a universal remote) which exposes a few methods such as watchMovie(). • The façade treats the various components as a sub system and calls on them to implement the watchMovie method. • So to watch a movie, we just call one method, watchMovie and it communicates with the Monitor, DVD, and Receiver for us. • The façade still leaves the subsystem accessible to be used directly. If you need the advanced functionality of the subsystem classes, they are available for use.
The Problem Complex system • Consisting of multiple subsystems • Each with its own interface, each with many methods Difficult for clients (blue) to deal with
Facade Solution Solution • Centralize subsystem interface • Simplify/reduce number of centralized methods • Façade presents new unified “face” to clients Facade
Removing the burden from beginning Java developers with a Façade (WinPlotter) SE-2811 Dr. Mark L. Hornick
Generic Pattern SE-2811 Dr. Mark L. Hornick
Facade Consequences Shields clients from subsystem components • Make subsystem easier to use Reduces coupling from client to subsystem classes • Allow internal classes to change freely • Permit “layering” of system function • Level of client-subsystem coupling • Make Facade an abstract class • Different concrete subclasses for different implementations of the subsystem. • Configure the façade object with different subsystem objects.
SE-2811 Dr. Mark L. Hornick
Facade Applications Interface to existing library • Unify or “clean up” complex interface Design layered system • Various service levels • Façade abstracts interface of each level Provide abstract interfaces • To alternative implementations