php facade模,PHP 设计模式之外观模式 Facade

简单描述

外观模式(Facade pattern)，为子系统中的一组接口提供一个统一的高层接口，使得子系统更容易使用。

外观模式又称为门面模式，它是一种对象结构型模式，遵循迪米特法则，又称最少知道原则。

模式动机

现代的软件系统都非常复杂，尽管我们已经想尽一切方法将其“分而治之”，把一个系统划分为好几个较小的子系统了，但是仍然可能会存在这样的问题：子系统内有非常多的类，客户端往往需要和许多对象打交道之后 才能完成想要完成的功能。

在我们的生活中医院就是这样的。一般的医院都会分为挂号、门诊、化验、收费、取药等。看病的病人要想治好自己的病(相当于一个客户端想要实现自己的功能)就要和医院的各个部门打交道。首先，病人需要挂号，然后门诊，如果医生要求化验的话，病人就要去化验，然后再回到门诊室，最后拿药，经过一系列复杂的过程后才能完成看病的过程。如下图所示：

解决方案：

解决这种不便的方式就是引入外观模式。如果我们在医院设立一个接待员的话，病人只负责和接待员接触，由接待员负责与医院的各个部门打交道，让接待员完全帮助我们实现“看病”各个操作，如下图所示：

模式结构图

外观模式的基本组成：

外观角色 Facade：模式的核心，被客户 Client 调用，知道各个子系统的概念。根据客户角色的需求定制功能组合。

子系统角色 SubSystem：实现子系统的功能。

客户角色 Client：调用 Facade 角色获取相应的功能。

优点

降低系统的复杂程度，对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式，客户代码将变得很简单，与之关联的对象也很少。

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

只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。

缺点

只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。

在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

使用场景

当要为一个复杂子系统提供一个简单接口时可以使用外观模式。该接口可以满足大多数用户的需求，而且用户也可以越过外观类直接访问子系统。

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

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

实例

下面以电脑开机为例子，正常情况下，我们只需要按下开机键即可，其他操作，比如 BIOS、打开操作系统这些操作是不需要用户关心的。

classOperatingSystem {publicfunction open() {

echo'打开操作系统';

}publicfunction shutdown() {

echo'关闭操作系统';

}publicfunction login() {

echo'登录操作系统';

}

}classBios {//硬件自检

publicfunction hardware_check() {

echo'硬件自检';

}//启动操作系统

publicfunction launch(OperatingSystem $os) {

echo'启动操作系统';

}//电源关闭

publicfunction power_down() {

echo'电源关闭';

}

}classFacade {private$os;private$bios;publicfunction __construct() {

$this->bios = newBios;

$this->os = newOperatingSystem;

}publicfunction turn_on() {

$this->bios->hardware_check();

$this->bios->launch($this->os);

$this->os->open();

$this->os->login();

}publicfunction turn_off() {

$this->os->shutdown();

$this->bios->power_down();

}

}//client

$facade = newFacade();//computer on

$facade->turn_on();

echo"
";//computer off

$facade->turn_off();

输出结果：

硬件自检 启动操作系统 打开操作系统 登录操作系统

关闭操作系统 电源关闭