Facade模式——设计模式学习(转载)

Facade模式

一 意图

  为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

二 动机

  将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。

达到该目标的途径之一是就是引入一个外观(Facade)对象,它为子系统中较一般的设施提供了一个单一而简单的界面。

将各个子系统整合起来作为Facade,提供给客户端使用。

  看下面这样一个系统:

  

    

  转变成:

  

    

三 适用性及其结构

  1. 当你要为一个复杂子系统提供一个简单接口时。
  2. 客户程序与抽象类的实现部分之间存在着很大的依赖性。
  3. 当你需要构建一个层次结构的子系统时,使用Facade模式定义子系统中每层的入口点。仅通过facade进行通讯。

结构:

  

    

Facede

  知道哪些子系统类负责处理请求。

  将客户的请求代理给适当的子系统对象。

Subsystem classes

  实现子系统的功能。

  处理由Facade对象指派的任务。

  没有facade的任何相关信息;即没有指向facade的指针。

  客户程序通过发送请求给Facade的方式与子系统通讯, Facade将这些消息转发给适当的子系统对象。

尽管是子系统中的有关对象在做实际工作,但Facade模式本身也必须将它的接口转换成子系统的接口。

  Facade模式有助于建立层次结构系统,也有助于对对象之间的依赖关系分层

  Facade模式可以消除复杂的循环依赖关系降低客户-子系统之间的耦合度

  使用Facade的客户程序不需要直接访问子系统对象。

四 代码实现  

1 subsystemClasses

以三种信息:SMS,MMS,PUSH为例:checkReady,getContent

/*----------------------------------------------------------------*//* class Base                                                     *//*----------------------------------------------------------------*/class Base{public:    Base(){};};

/*----------------------------------------------------------------*//* class SmsUtil                                                  *//*----------------------------------------------------------------*/class SmsUtil: public Base{#define SMS_CONTENT "I am sms content"public:    SmsUtil(){}    bool checkReady()    {        cout<<"SmsUtil checkReady"<<endl;        return true;    }    bool getSmsContent(int msg_id,char* pContent)    {        cout<<"SmsUtil getSmsContent"<<endl;        strcpy(pContent,SMS_CONTENT);        return true;    }};

/*----------------------------------------------------------------*//* class MmsUtil                                                  *//*----------------------------------------------------------------*/class MmsUtil: public Base{#define MMS_CONTENT "I am mms content"public:    MmsUtil(){}    bool checkReady()    {        cout<<"MmsUtil checkReady"<<endl;        return true;    }    bool getMmsContent(int msg_id,char* pContent)    {        cout<<"MmsUtil getMmsContent"<<endl;        strcpy(pContent,MMS_CONTENT);        return true;    }};

/*----------------------------------------------------------------*//* class PushUtil                                                 *//*----------------------------------------------------------------*/class PushUtil: public Base{#define PUSH_CONTENT "I am push content"public:    PushUtil(){}    bool checkReady()    {        cout<<"PushUtil checkReady"<<endl;        return true;    }    bool getPushContent(int msg_id,char* pContent)    {        cout<<"PushUtil getPushContent"<<endl;        strcpy(pContent,PUSH_CONTENT);        return true;    }};


2 Facade ——单例类

/*----------------------------------------------------------------*//* class MsgFacade                                                *//*----------------------------------------------------------------*/enum MsgType{    SMS,    MMS,    PUSH,    MSG_ALL};

class MsgFacade: public Base{protected:    MsgFacade()    {        m_sms = new SmsUtil();        m_mms = new MmsUtil();        m_push = new PushUtil();    }public:    static MsgFacade* getInstance()    {        if (s_instance == NULL)        {            s_instance = new MsgFacade();        }

return s_instance;    }    static void closeInstance()    {        delete s_instance;    }public:    bool checkReady(int type)    {        bool resutl = false;

resutl = m_sms->checkReady();        resutl &= m_mms->checkReady();        resutl &= m_push->checkReady();

return resutl;    }    bool getMsgContent(int type,int msg_id,char* pContent)    {        switch(type)        {            case SMS:            {                m_sms->getSmsContent(msg_id,pContent);                break;            }            case MMS:            {                m_mms->getMmsContent(msg_id,pContent);                break;            }            case PUSH:            {                m_push->getPushContent(msg_id,pContent);                break;            }            default:                break;        }

return true;    }private:    SmsUtil* m_sms;    MmsUtil* m_mms;    PushUtil* m_push;

static MsgFacade* s_instance;};MsgFacade* MsgFacade::s_instance = NULL;

3 Test

#include "facade.h"

int main(){    MsgFacade* msg = MsgFacade::getInstance();    msg->checkReady(MSG_ALL);

cout<<endl;    char content[100] = {0};

msg->getMsgContent(SMS,0,content);    cout<<content<<endl;

msg->getMsgContent(MMS,0,content);    cout<<content<<endl;

msg->getMsgContent(PUSH,0,content);    cout<<content<<endl;

return 0;}

4 Result

SmsUtil checkReadyMmsUtil checkReadyPushUtil checkReady

SmsUtil getSmsContentI am sms contentMmsUtil getMmsContentI am mms contentPushUtil getPushContentI am push content

  仅需要一个Facade对象,因此Facade对象通常属于Singleton 模式

 

时间: 2024-10-10 05:40:03

Facade模式——设计模式学习(转载)的相关文章

简单工厂模式、工厂方法模式和抽象工厂模式-设计模式学习

1.简单工厂模式 简单工厂模式是属于创建型模式,又叫做静态工厂方法(StaticFactory Method)模式,但不属于23种GOF设计模式之一.简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例.简单工厂模式是工厂模式家族中最简单实用的模式,可以理解为是不同工厂模式的一个特殊实现. 工厂(Creator)角色 简单工厂模式的核心,它负责实现创建所有实例的内部逻辑.工厂类的创建产品类的方法可以被外界直接调用,创建所需的产品对象. 抽象产品(Product)角色 简单工厂模式所创建的所有

备忘录模式 - 设计模式学习

备忘录模式(Memento):在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态.这样以后就可将该对象恢复到原先保存的状态. 以下给出备忘录模式的UML图: Originator(发起人):负责创建一个备忘录Memento,用以记录当前时刻它的内部状态,并可使用备忘录恢复内部状态.Originator可根据需要决定Memento存储Originator的哪些内部状态. Memento(备忘录):负责存储Originnator对象的内部状态,并可防止Originator以外

桥接模式 - 设计模式学习

合成/聚合复用原则(CARP),尽量使用合成/聚合,尽量不要使用类继承. 合成和聚合都是关联的特殊种类.聚合表示一种弱的“拥有关系”,体现的是A对象可以包含B对象,但B对象不一定是A对象的一部分:合成则是一种枪的‘拥有’关系,体现了严格的部分和整体的关系,部分和整体的声明周期一样.比方说,大雁有两个翅膀,翅膀与大雁是部分和整体的关系,并且它们的声明周期是相同的,于是大雁和翅膀就是合成关系.而大雁是群居动物,所以每只大雁都是属于一个雁群,一个雁群可以有多只大雁,所以大雁和雁群是聚合关系. 合成/聚

职责链模式 - 设计模式学习

职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系.将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它位置. 下面给出职责链模式的结构图: 下面给出职责链模式的基本代码结构: namespace ConsoleApplication1 { //Handler类,定义一个处理请示的接口 abstract class Handler { protected Handler successor; publ

组合模式 - 设计模式学习

组合模式(Composite),将对象组合成属性结构以表示'部分-整体'的层次结构,组合模式使得用户对单个对象和组合对象的使用具有一致性. 下面给出组合模式的UML图: 来看组合模式的基本代码结构: namespace ConsoleApplication1 { //Component为组合中的对象声明接口 abstract class Component { protected string name; public Component(string name) { this.name = n

命令模式 - 设计模式学习

命令模式(Command),将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化:对请求排队或记录请求日志,以及支持可撤销操作. 下面给出命令模式的结构图: 下面是命令模式的基本结构代码: namespace ConsoleApplication1 { abstract class Command { protected Receiver receiver; public Command(Receiver receiver) { this.receiver = receiver; }

抽象工厂模式 - 设计模式学习

抽象工厂模式(Abstract Factory),提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类. 以下给出抽象工厂方法模式的UML图: 回到<大话设计模式>里面的双数据库访问的例子: namespace ConsoleApplication1 { class User { private int _id; public int ID { get { return _id; } set { _id = value; } } private string _name; pub

享元模式 - 设计模式学习

享元模式(Flyweight),运用共享技术有效地支持大量细粒度的对象. 下面给出享元模式的结构图: 下面给出享元模式的基本代码结构: namespace ConsoleApplication1 { //Flyweight类,它是所有具体享元类的超类或接口,通过这个接口,Flyweight可以接受并作用于外部状态 abstract class Flyweight { public abstract void Operation(int extrinsicstate); } //ConcreteF

解释器模式 - 设计模式学习

解释器模式(interpreter),给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子. 解释器模式需要解决的是,如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言的句子.这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题. 下面给出解释器模式的结构图: 下面给出解释器模式的基本代码结构: namespace ConsoleApplication1 { //AbstractExpresstion(抽