CSC/ECE 517 Fall 2012/ch2b 2w42 aa

Introduction

Facade Pattern

Intent
1) Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
2) Wrap a complicated subsystem with a simpler interface.

Non-Software examples
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems. Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes.

With a Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

using System;
using System.Collections.Generic;

namespace Yanesh.DesignPatterns.Facade
{
   public class OrderFacade
   {
       //Places an Order and Returns an Order ID
       public int placeOrder(int CustomerID, List<BasketItem> Products)
       {
           Order anOrder = new Order();
           OrderLine anOrderLine = new OrderLine();
           Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
           int OrderId = anOrder.requestOrderID();

           anOrder.createOrder(OrderId, DespatchAddress);
           anOrderLine.addOrderLinesToOrder(OrderId, Products);

           return OrderId;
       }
   }

   //order class
   public class Order
   {
       public int requestOrderID()
       {
           //Creates and Returns a Unique Order ID
       }

       public void createOrder(int OrderId, Address DespatchAddress)
       {
       }
   }

   //OrderLine Class
   public class OrderLine
   {
       public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
       {
       }
   }
    
   //Public Customer
   public class Address
   {
       public static Address getCustomerDespatchAddress(int CustomerID)
       {
           return new Address();
       }
       //Address properties
   }

   public class BasketItem
   {
       //BasketItem Properties
   }
}

Problem
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem.

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object.

Abstract Factory Pattern

Intent
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”.
3) The new operator considered harmful.

Problem

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code.

Discussion

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton.

Adapter Pattern

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.
2)Wrap an existing class with a new interface.
3)Impedance match an old component to a new system.

Two types of adapter patterns
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object).
2)Class Adapter pattern— implemented withmultiple inheritance

Problem
An “off the shelf” component offers compelling functionality that you would like to reuse, but its “view of the world” is not compatible with the philosophy and architecture of the system currently being developed.

Discussion
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

Differences n similarities between Adapter and Facade

1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line

A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.