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

阅读时长：5分钟

技术预备：熟悉Laravel的使用

外观模式（Facade）

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

看过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）

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

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

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

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

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

而如果某一天，我们需要替换掉这个类，只需要将这里的DatabaseManager替换成你要的类，并不需要去修改代码逻辑。

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

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

三、结语

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

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

----- End -----

更多好文

请扫描下面二维码

欢迎关注~