Facade模式是否违反SOLID原则？

Question

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

已更新

我的意见：

如果您不直接调用方法，则会违反
• SRP ，但是 交易，记录，错误处理（我已经看过很多次）。即使只是调用其他方法，我也有疑问。
违反了

• OCP ，因为您会向立面添加更多方法

违反

• LSP / ISP ，因为使用者/客户端具有依赖性太多的客户端不需要的依赖。

• DIP ，在我看来，只要界面本身只暴露抽象或DTO，就不会违反。

SOLID 一般来说，我认为小，稳定，从而可组合接口。

facade 往往是相反的大和不稳定。

Answer 1

一般而言，在不考虑任何实现细节的情况下，我们可以将 Facade 视为使用组合和封装。更高级别的 Wrapper 类总是与任何客户端进行对话，并且包装器中包含的子系统是真正完成工作的那些。

示例：

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（许多模式）的选择仍然是个人风格。