设计模式-外观模式

外观模式是一种使用频率非常高的结构型设计模式, 它通过引入一个外观角色来简化客户端和子系统之间的交互, 为复杂的子系统提供统一的入口, 降低子系统与客户端的耦合度, 且客户端调用非常方便.

1. 外观模式概述

在软件开发中, 有时候为了完成一项较为复杂的功能, 一个客户类需要和多个业务类交互, 而这些需要交互的业务类经常作为一个整体出现, 由于涉及到的类比较多, 导致使用时候代码较为复杂, 此时特别需要一个类似服务员一样的角色, 由他来负责和多个业务类进行交互, 而客户端只需要与该类交互. 外观模式中, 引入一个新的外观类(Facade)[b]来实现该功能, 外观类充当软件系统中的"服务员", 它为多个业务类的调用提供一个统一的入口, 简化了类与类之间的交互. 在外观模式中, 那些需要交互的业务类被称为子系统(SubsSystem)[/b]. 如果没有外观类，那么每个客户类需要和多个子系统之间进行复杂的交互，系统的耦合度将很大，如图2(A)所示；而引入外观类之后，客户类只需要直接与外观类交互，客户类与子系统之间原有的复杂引用关系由外观类来实现，从而降低了系统的耦合度，如图2(B)所示。



在外观模式中, 一个子系统的外部与其内部的通信通过一个统一的外观类进行, 外观类将客户类和子系统的内部的复杂性分隔开, 使得客户类只需与外观角色打交道, 而不需要与子系统内部的很多对象打交道.

外观模式: 为子系统中的一组接口提供统一的入口. 外观模式定义一个高层接口, 这个接口使得这一子系统更加容易被使用.

外观模式又称为门面模式, 它是一种对象结构型模式. 外观模式是迪米特法则的一种具体实现, 通过引入一个新的外观角色可以降低原油系统的复杂度, 同时降低客户类与子系统的耦合度.

2. 外观模式的实现

例一:

给自己举个最熟悉的例子:

MJRefresh

, 其中

UIScrollView+MJRefresh

就是一个外观类. 类抛出的方法和属性如下所示, 还是蛮简单的, 使用时候, 我们只需要和这个外观类进行交互, 将自己需要的header或者footer注入到外观类中, 到底什么时候用到这些对象什么时候会调用待header的相关方法, 就不是我们关系的事情了, 这些复杂的逻辑都被放在外观类中进行处理,.

这样, 使用框架的程序员们和封装框架的人之间通过MJRefresh这个扩展联系起来, 我们不需要关心MJRefresh内部实现多么复杂, 也不必关心它的内部逻辑, 可以通过外观类简单的使用MJRefresh. 这就是外观模式.

@class MJRefreshHeader, MJRefreshFooter;

@interface UIScrollView (MJRefresh)
/** 下拉刷新控件 */
@property (strong, nonatomic) MJRefreshHeader *mj_header;
@property (strong, nonatomic) MJRefreshHeader *header MJRefreshDeprecated("使用mj_header");
/** 上拉刷新控件 */
@property (strong, nonatomic) MJRefreshFooter *mj_footer;
@property (strong, nonatomic) MJRefreshFooter *footer MJRefreshDeprecated("使用mj_footer");

#pragma mark - other
- (NSInteger)mj_totalDataCount;
@property (copy, nonatomic) void (^mj_reloadDataBlock)(NSInteger totalDataCount);
@end

例二:

比如一个软件的文件加密模块, 该软件可以将文件加密然后把存储到一个新文件中, 具体流程分为: 读取文件,加密, 保存加密文件. 为了让代码独立重用, 让设计更加符合单一职责原则, 将这三个操作的业务代码封装到三个不同的类中.

使用外观类组合加密操作, 如下图, 其中EncryptFacade是一个外观类, 加密操作分为三个操作, 但是我们在使用加密时候不必关心加密的过程, 只需要调用 FileEncrypt方法即可完成读取/加密/写入新文件.

3. 抽象外观类

如上例二途中所示, 标准的外观模式中, 如果要更换外观类的子系统, 则必须修改外观类的客户端源代码, 这将违背开闭原则. 因此可以引进抽象外观类来对系统进行改进, 在一定程度上可以解决该问题. 引入抽象外观类之后, 客户端可以针对抽象外观类进行编程, 对于新的业务需求可以在不修改原有外观类的情况下修改具体的实现类. 这样可以适配不同的加密算法.

5. 外观模式效果与适用场景

外观模式是一种使用频率非常高的设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，使子系统与客户端的耦合度降低，且客户端调用非常方便。外观模式并不给系统增加任何新功能，它仅仅是简化调用接口。在几乎所有的软件中都能够找到外观模式的应用，如绝大多数B/S系统都有一个首页或者导航页面，大部分C/S系统都提供了菜单或者工具栏，在这里，首页和导航页面就是B/S系统的外观角色，而菜单和工具栏就是C/S系统的外观角色，通过它们用户可以快速访问子系统，降低了系统的复杂程度。所有涉及到与多个业务对象交互的场景都可以考虑使用外观模式进行重构。

5.1 模式优点

外观模式的主要优点如下：

(1) 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。

(2) 它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可。

(3) 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。

5.2 模式缺点

外观模式的主要缺点如下：

(1) 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活 性。

(2) 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。

5.3 模式适用场景

在以下情况下可以考虑使用外观模式：

(1) 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。

(2) 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。

(3) 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

reference: http://blog.csdn.net/lovelion/article/details/8258121