外观模式（门面模式）

定义：为系统中的一组接口提供一个统一的接口。 外观定义了一个高层接口，让子系统更易于使用。

例子1）：我不想开车， 叫司机开车，开车里面的细节我就不用管了
例子2）:买基金

外观模式为子系统中一组不同的接口提供统一的接口。 外观定义了上层接口，通过降低复杂度和隐藏系统之间的以来依存关系， 让子系统更易于使用。

有些客户端值需要子系统的某些基本行为，而对子系统的类不做太多定制， 外观为这样的客户端提供简化的接口。

例子1）叫出租车司机的例子

上面出租车的例子：

- (void) driveToLocation:(CGPoint) x
{
  // ...
  
  // set off the taximeter  计程表
  Taximeter *meter = [[Taximeter alloc] init];
  [meter start];
  
  // operate the vehicle 开车的步骤
  // until location x is reached
  Car *car = [[Car alloc] init];
  [car releaseBrakes];
  [car changeGears];
  [car pressAccelerator];
  
  // ...
  
  // when it's reached location x
  // then stop the car and taximeter
  [car releaseAccelerator];
  [car pressBrakes];
  [meter stop];
}

客户字需要调用这个方法要到哪里就好了

例子2）投资基金（而不买股票）

买股票
买基金

感觉就是我们平常对复杂的调用，抽象出来一个简单的方法然后进行调用。

何时使用外观模式

两种常见的场景
1） 子系统正逐渐变得复杂。 应用模式的过程中演变出许多类。可以使用外观为这些子系统类提供一个较简单的接口
2）可以使用外观对子系统的分层。 每个子系统级别有一个外观作为入口点。 让它们通过其外观进行通信， 可以简化它们的以来关系。

#何时使用外观模式

1） 首先在设计初期阶段，应该要意识的将两个不同的两个层分离；eg： 经典的三层架构， 就需要考虑在数据访问层和业务逻辑层和表示层的之间建立外观Facade， 为复杂的子系统提供更为简单的接口，大大降低耦合度。
2）在开发阶段，子系统往往因为不断的重构艳花而变得越来越复杂，大多数的模式使用时也都会产生很多很小的累，这本是好事，但是也给外部调用它们的用户程序带来了使用的困难，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。
3）在维护一个遗留的大型系统时， 可能这个系统已经北场难以维护和扩展了，但因为它包含非常中啊哟的功能，新的需求开发必须依赖于它。 这个时候外观Facade非常合适。

这里需要思考一个问题：策略模式和外观模式有什么不一样的地方？

策略：策略里面封装的是每个独立的算法； 策略是对算法封装之后的决策。
外观： 是对子系统提供简单的上层或者一个简单的接口方法调用。 算法只是针对单个内容的独立进行封装。 当然，如果一个算法里面包含很多算法，很复杂，里面可以进行提供搞一个简单的接口

策略更像是一个并列的广度； 外观更加像是对串行过程的封装。 维度思考不同。

这些设计模式：主要针对的是， 你要写的代码， 策略模式：思考里面的算法的独立写法。 外观：思考怎么提供简单的接口。