Facade模式是否违反SOLID原则？

Posted 2021-05-06

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

更新

我的意见：

• 如果您不直接调用方法，而是执行事务，日志记录，错误处理（我已经看过很多次），违反了SRP。即使只是调用其他方法，我也有疑问。
• 违反了OCP，因为您将在外观中添加更多方法
• 违反了LSP / ISP，因为消费者/客户端具有依赖性太多的客户端不需要的依赖性。
• DIP，在我看来，只要界面本身只暴露抽象或DTO，就不会违反。

一般而言，SOLID是关于小型，稳定且由此可组合的接口。

立面往往是相反的大而不稳定。

答案

在没有考虑任何实现细节的一般想法中，我们可以将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. 子系统与包装器紧密耦合。
3. 这是一些程序性的，远离面向对象的东西。

使用Facade（许多模式）的选择仍然是个人风格。