Motivation

Not long ago, I was reviewing some contents regarding Design Patterns and then I came across some interesting questions:
- Is the Facade a pattern or would it be considered an anti-pattern?
- Does the Facade Pattern violate any SOLID principle?
In this article I will not explain Facade pattern, SOLID principles or how to implement them. I will just go over the main idea and superficial definitions regarding these concepts. I assume that if you are reading this article, you probably already know the concepts behind these patterns/principles, but if you are interested in understanding them better, you can check it out here:

• Facade Pattern
• SOLID

Facade Pattern

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

That is the pattern intent we can find in the book Design Patterns: Elements of Reusable Object-Oriented Software.

SOLID principles

SRP - Single Responsibility principle: "There should never be more than one reason for a class to change." In other words, every class should have only one responsibility.

OCP - Open Closed principle: "Software entities should be open for extension, but closed for modification” In other words, We should always choose to write code that does not need to be changed every time requirements change.

LSP - Liskov Substitution principle: “Objects of a superclass should be replaced by objects of its subclasses without breaking the application.” In other words, if we replace an object reference from the superclass with an object from any of its subclasses, the program should continue working properly.

ISP - Interface Segregation principle: "Many client-specific interfaces are better than one general-purpose interface." In other words, clients should not be forced to depend upon interfaces that they do not use.

DIP - Dependency Inversion principle: "Depend upon abstractions, not concretions." In other words, high-level modules should not depend on low-level modules. Both should depend on the abstraction.

Which of the SOLID principles does the Facade Pattern supposedly violate?

Single Responsibility Principle (SRP) is the first principle that always blows developers minds, because one of its premises states that a software entity should only have one reason to be changed. Facade pattern, on the other hand, can wrap multiple subsystems with a unified interface, which sparks up discussion on whether or not it can break SRP, so, let's break it down to make this question clearer.
A wrapper (Facade) class is supposed to have just one responsibility, which is to orchestrate calls in a logical order to achieve any specific goal, abstracting implementation details and exposing an interface that is simple and unified for the developer, therefore, the question would be, What reasons can lead Facade to be changed? Maybe a different sequence of the calls or an implementation of another required step (we will discuss that later).
Just keep in mind that, in this case, if you consider that it violates the SRP, without a Facade this principle is violated too, since somewhere in the code the sequence of steps will have to be called as well, but, of course we are considering that other SOLID principles like DIP are being used in your solution, given that Facade pattern or any other pattern should depend on abstractions, not on concretions.
If we do not depend on implementation details in our solution, in theory, we only have one responsibility in our Facade, which in this case would be to “provide a unified interface to a set of interfaces in a subsystem”.

Open-Closed Principle (OCP) is another pattern that also raises some discussions, regarding the violation of this principle when implementing the Facade.
Imagine the scenario mentioned previously, where we have the unified interface for subsystems implemented, working properly and suddenly we need to add a new step or another subsystem in our solution. Without considering any real code, it is difficult to say whether the hypothetical new requirement violates the OCP or not. Just thinking about it in a simpler way, this principle will be violated. Just to make it clear, it doesn't mean that there is a problem rooted in the Facade pattern, but that the implementation may have some problems caused by the way the developer coded the solution, and of course it can be refactored and fixed. A suggestion would be a combination of other known patterns like, Decorator, Chain Of Responsibility or Tube and Filter for example.

Conclusion

Is Facade a Pattern or Anti-pattern? Of course it is a pattern, one of the most frequently used patterns by developers and it does not violate any SOLID principle by itself, but it can lead developers to make mistakes, especially when other principles, patterns, and good practices are neglected during development.