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

Question

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

更新

我的意见：

• SRP 被违反，当你不只是直接调用方法，而是 诸如事务、日志记录、错误处理（我见过很多次）之类的东西。即使只是调用其他方法，我也有疑问。

• OCP被违反了，因为你会在facade中添加更多的方法

• LSP/ISP 被违反，因为消费者/客户端有依赖，将有太多的方法，客户端不需要。

• DIP，在我看来，只要接口本身只公开抽象或 DTO，就不会违反。

在我看来，

SOLID 总体上是关于small、stable 以及因此composable 的接口。

门面往往是相反的大和不稳定。

Answer 1

总的来说，不考虑任何实现细节，我们可以将Facade视为一种使用Composition and Encapsulation隐藏一组具有更高级别包装类的子系统的方法>。更高级别的 Wrapper 类是始终与任何客户端对话的类，而包含在 wrapper 内的 Sub-systems 是真正在做这些工作的类。

例子：

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 原则。

1. SRP：您应该认为，包装类违反了这一原则，因为它的职责不止一个。但另一方面，它只是调用其他一些人来执行它们，而不是使用包装器来保存实现。无论如何，这种想法可能非常个人化。
2. OCP：当然可以，如果您要添加更多子系统/功能。同时，您可以使用一些现代的实现绑定框架来避免在这种情况下违反 OCP。
3. LSP：一般我没有找到。但可能存在特定于实现的情况，而不是模式。
4. ISP：与 LSP 相同。
5. DIP：与 LSP、ISP 相同。

关于将 Facade 视为一种反模式（Facade 的缺点），

1. 可以看出，它正在增加维护工作量。对于某些更改，您必须更改子系统实现 + 相应的包装器调用。
2. 子系统与 Wrapper 紧密耦合。
3. 这是一些程序性的，有点偏离面向对象。

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