design-patterns - 外观模式是否违反了 SOLID 原则？

Question

我问我自己，外观模式是否违反了 SOLID 原则，以及模式本身是否是反模式。

更新

我的意见:

建议零售价 被违反了，当你不只是直接调用方法，而是做
诸如事务、日志记录、错误处理(我见过很多次)之类的东西。即使只是调用其他方法，我也有疑问。

OCP 被违反了，因为你会在门面添加更多的方法

语言服务商/网络服务商违反了，因为消费者/客户端具有依赖关系，该依赖关系将具有太多的方法，而客户端不需要。

直拨 , 在我看来，只要接口(interface)本身只公开抽象或 DTO，就不会违反。

固体总的来说，我认为 小 , 稳定从而 可组合 接口(interface)。

立面往往相反 大和 不稳定 .

Answer 1

总体思路不考虑任何实现细节，我们可以考虑 门面 作为使用 隐藏一组具有更高级别包装类的子系统的方法组成与封装 .上级包装 类是总是与任何客户交谈的类，子系统 包含在包装器内的是真正在做这些工作的那些。

例子:

public class Bulb{

    public void on(){
        //logic to turn on the bulb.
    }

}

public class Room{

   private Bulb bulb;

   public void lightUp(){
        this.bulb.on();
   }
}

上面的 Bulb 是一个子系统，Room 是包装器(Facade)。因此，客户希望看到它直接照亮了房间，并且不想知道它必须用灯泡做什么。

所以回到你的问题，如果我们一一采用 SOLID 原则。

SRP:你应该认为，包装类违反了这个原则，因为它做的不止一个职责。但另一方面，它只是调用其他一些人来执行它们，而不是使用包装器来保存实现。无论如何，这种想法可能非常个人化。

OCP:当然可以，如果您要添加更多子系统/功能。同时，您可以使用一些现代的实现绑定(bind)框架来避免在这种情况下违反 OCP。

LSP:总的来说，我没有找到。但是可能存在特定于实现的情况，而不是模式。

ISP:与 LSP 相同。

DIP:同LSP、ISP。

关于将 Facade 视为一种反模式(Facade 的缺点)，

可以看出，它正在增加维护工作量。对于某些更改，您必须更改子系统实现 + 相应的包装器调用。

子系统与 Wrapper 紧密耦合。

这是一些程序性的，有点远离面向对象。

仍然会根据个人喜好选择使用 Facade(许多模式)。