Laravel框架中如何进行外观模式的高级应用与解析？

本文共计1585个文字，预计阅读时间需要7分钟。

根据单一职责原则，在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系最小化，通过引入一个外观对象，为子系统提供简单的单一接口。外观模式（也称为迪米特法则）是这种设计的体现，通过引入新的外观类，可以降低原有系统的复杂度，同时降低客户类与子系统类之间的耦合度。

外观模式要求子系统的外部与内部通信通过一个统一的接口进行，这样，客户端只需与外观类交互，而无需了解子系统内部的复杂性。外观类将客户的请求转化为对子系统的请求，从而分离了客户端与子系统之间的直接依赖。

外观模式的目标在于：

缺点

外观模式的缺点

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

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

模式扩展

• 一个系统有多个外观类

  在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。在很多情况下为了节约系统资源，一般将外观类设计为单例类。当然这并不意味着在整个系统里只能有一个外观类，在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。

• 不要试图通过外观类为子系统增加新行为

  不要通过继承一个外观类在子系统中加入新的行为，这种做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。