浅谈Laravel中的设计模式（二） Facade 外观模式

阅读时长：5分钟

技术预备：熟悉Laravel的使用

外观模式（Facade）

1、首先什么是外观模式呢？

看过Laravel文档的童鞋必定听过门面模式，当初第一次看到这个词我是很懵逼的，门？脸？门脸都能有模式？？

查阅以后，其实应该叫外观模式。

简单来讲，就是为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

咱们知道，定义都是很枯燥的，因此让咱们来举个栗子：

$students = DB::table('student')->get();
$students = $students->toArray();
复制代码

使用过Laravel框架的童鞋们必定见过这种代码。 只须要静态调用DB类，就可以使用这个类里面的方法了，其实这种调用就叫作外观模式。 在Laravel中很是多经常使用的类都使用到了外观模式，例如DB、Session等。

能够看到，在这种Facade类中，都只定义了一个方法getFacadeAccessor()，那么为何这个方法只返回“db”就可使用了呢？咱们能够去翻翻Facade类源码。

（有些童鞋不知道何时叫方法何时叫函数。若是一个代码块是独立的，那的确能够称为函数（function），但若是代码块是在类里面的，应该要称为方法（method））

能够看到，Facade这个抽象类实现了__callStatic()静态调用方法，其中又调用了getFacadeRoot()，而getFacadeRoot()里就调用了刚才的getFacadeAccessor()获取服务提供者的别名，在DB类中即“db”。 resolveFacadeInstance()就经过Laravel的容器机制把DB的实际对象解析了出来，这样既实现了单例模式，又容易调用。

（关于容器机制不了解的童鞋，请关注之后的文章哦o(￣▽￣)d）

2、外观模式有什么用呢？

在一个庞大的系统中，充满了许多的子系统和子模块协做，而外部对于子系统的调用会造成很是大的耦合。

这样的耦合显然就违背了咱们拆解系统的初衷，也让系统拆分失去了意义。

而外观模式其实就是为了将调用和框架解耦，减小系统中的相互依赖。 咱们能够在Laravel的Application类中看到别名对应的实际类：

在这里，“db”对应的是\Illuminate\Database\DatabaseManager::class这个类。

而若是某一天，咱们须要替换掉这个类，只须要将这里的DatabaseManager替换成你要的类，并不须要去修改代码逻辑。

（估计有童鞋会说：“赵童鞋你耍我呢，怎么可能替换框架的类呢？”，当一个项目足够庞大的时候，将路由类，Application容器类替换掉都是有可能的）

可是外观模式也不是没有缺点的，不符合开闭原则，若是要改东西很麻烦，继承重写都不合适。 须要注意的是，咱们不该该经过实现或者继承一个外观类，为子系统添加新的功能。 这是典型错误的作法，其违背了外观模式的初衷。

3、结语

外观模式就到这里一段落了~

若是有哪里解释不清楚的话，欢迎留言哦~

----- End -----

更多好文

请扫描下面二维码

欢迎关注~