Does the Facade Pattern violates the SOLID principles?

Question

I ask my self if the Facade Pattern violates the SOLID principles and if the pattern itself is an Anti Pattern.

UPDATED

My Opinions:

• SRP is violated, when you don't just call methods directly, but do things like Transactions, Logging, Error Handling (What I have seen a lot of times). Even with just calling other methods I am in doubt.

• OCP is violated, because you will add more methods to the facade

• LSP/ISP is violated, because the consumer/client has dependency that will have too much methods, which the client does not need.

• DIP, is in my opinion not violated as long as the interface itself only exposes abstraction or DTOs.

SOLID in general is in my opinion about small, stable and thereby composable interfaces.

A facade tends to be the opposite big and not stable.

Answer 1

In general idea without considering any implementation specifics, we can consider Facade as a way of hiding a set of sub-systems with a higher level wrapper class using Composition and Encapsulation. The higher level Wrapper class is the one that always talks with any client and the Sub-systems consisted inside the wrapper are the ones that are really doing the jobs.

Example:

public class Bulb{

    public void on(){
        //logic to turn on the bulb.
    }

}

public class Room{

   private Bulb bulb;

   public void lightUp(){
        this.bulb.on();
   }
}

In above Bulb is a sub-system and Room is the wrapper (Facade). So a client would like to see as it is directly lighting up the room and not interested in knowing what it has to be done with the bulb.

So back into your question, If we take SOLID principles one by one.

1. SRP: You should be thinking that, the wrapper class violates this principle, because it is doing more than a single duty. But on the other hand, it is just calling some others to do them, and not holding the implementation with the wrapper. Anyway that thought can be much personal one.
2. OCP: Definitely yes, if you are adding some more subsystems/functionalities. Meantime you can use some modern implementation binding framework to avoid violating OCP in this situation.
3. LSP: In general I don't find any. But there can be situations which are implementation specific, not with the pattern.
4. ISP: Same as LSP.
5. DIP: Same as LSP, ISP.

And about considering Facade as an anti-pattern (Cons of Facade),

1. One can see, It is increasing the maintenance effort. For some changes you have to change the sub-system(s) implementation + respective wrapper calls.
2. Sub-systems are tightly coupled with the Wrapper.
3. It is some what procedural and a bit away from object orientation.

Still the choice of using Facade(Many patterns) would be by personal flavor.