Facade 模式是否违反了 SOLID 原则？

Question

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

更新

我的意见：

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

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

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

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

SOLID一般是我约的意见小，稳定，从而组合的接口。

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

Answer 1

一般来说，不考虑任何实现细节，我们可以将Facade视为一种使用Composition 和 Encapsulation隐藏具有更高级别包装类的子系统的方法。更高级别的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(Many patterns) 将取决于个人风格。