iOS 设计模式-结构模式-外观模式

2016-03-16

本篇文章小编向大家讲述外观模式相关知识和实现方式，以及在我们开发过程中使用情况。

外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

在外观模式中有三个角色：外观角色(Facade) 和子系统角色(SubSystem)。

简介

外观角色(Facade)

客户端可以调用外观角色的方法，在外观角色中可以知道相关的一个或者多个子系统的功能和责任。在正常时，将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。

子系统角色(SubSystem)

软件系统中有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能。每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求。子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

模式结构

外观模式结构图如下：

屏幕快照 2017-09-08 17.37.14.png

由上图可以看出在上面外观模式实现过程中，外观角色(Facade) 来调用子系统角色(SubSystem)。在满足迪米特原则的基础同时，外观模式也通过给出一个外观角色来给系统相关的方法来访问其他的子系统。这样就降低在开发过程中耦合想象。

模式实现

在编码实现的过程中小编发现我们会对一些方法进行类抽取，这样可以减少在修改时的灵活性和减少耦合。但是当我们在抽取一定的程度，小编发现随着类的不断增多类之间的引用情况会大大增加。这样不但没有起到减少耦合的效果，反而增加耦合。这里外观模式就可以很好解决我们目前遇到状况，减少在方法抽取过程中耦合情况。

下面一段 C++ 实例代码模拟公司的老板对员工工作的安排情况，代码实现如下：

//工人
class worker {
public:
    void produce() {
        //生产产品
    };
};

//主管
class charger {
public:
    void arrangeWork () {
        //安排工人工作
    };
};

//秘书
class secretary {
public:
    void scheduling () {
        //日常行程安排
    };
    
private:
    void call();//打电话
};

//外观角色
class facade {
//私有方法
private:
    worker worker;
    charger charger;
    secretary secretary;
    
public:
    void taskAssignment () {
        worker.produce();
        charger.arrangeWork();
        secretary.scheduling();
    };
};

//BOSS
class boss {
    int main() {
        //模拟 boss 指派员工的具体工作
        facade facade;
        facade.taskAssignment();
        
        return 0;
    };
};

抽象外观类

上面的情况在公司初期阶段 BOSS 需要安排公司具体任务，但是随着公司的业务和规模的扩大公司需要提拔一位副总来完成相关的工作。这样就会较少 BOSS 具体安排工作内容，更好的可以实现公司的战略布局和相关业务整合。

但是在前面使用外观模式情况下，如果我们修改相关的 BOSS 指派具体工作人员或者是岗位有所增加。那么就需要修改 facade 类文件，这样我们就违反了开闭原则。为了解决此类问题呢，我们可以对外观模式采用抽象方法的原则来实现更好的解决。

修改的代码如下：

//副总
class vicePresident {
public:
    void concreteTaskAssignmen() {
        //代替老板安排具体的工作
    };
};

//抽象外观角色
class abstractFacade {
public:
    void taskAssignment();
};

//具体的外观角色
class concreteFacade : public abstractFacade{
public:
    //重写父类的方法
    void taskAssignment() {
        secretary.scheduling();
        vicePresident.concreteTaskAssignmen();
    }
    
private:
    vicePresident vicePresident;
    secretary secretary;
};

class boss {
    int main() {
        //模拟 boss 指派员工的具体工作
        concreteFacade facade;
        facade.taskAssignment();
        
        return 0;
    };
};

外观模式优缺点

优点

1) 对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。
2) 实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可。
3) 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。

缺点

1) 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
2) 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。

参考资料：
深入浅出外观模式