9

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.

Rookian
  • 19,841
  • 28
  • 110
  • 180
  • You mean all SOLID principles?? or some specific one? – Supun Wijerathne Aug 22 '16 at 14:09
  • I would say SRP, Liskovk and Interface Segregation. – Rookian Aug 22 '16 at 14:12
  • 1
    In general I can myself see violation of OCP. And you might refer the Facade class, as violating SRP. Rest of your question might be pretty much implementation specific. Could you please elaborate with an example, giving where it violates those principles? or a link of a specific implementation you found?? – Supun Wijerathne Aug 22 '16 at 14:34
  • 2
    only correct answer is "it depends", oh and `subjective` – mxmissile Aug 22 '16 at 15:25
  • @Rookian just saw your edit. In your opinions, I think for SRP and OCP, I have put same thought in my answer. :) One addition is you have to violate OCP whenever you have a new requirement to add inside an existing file, which is not only 'Facade' specific. But for LSP/ISP, I don't understand your point. It's true that the client is dependent with Facade. Does it mean it's violating LSP/ISP ?? – Supun Wijerathne Aug 31 '16 at 02:48
  • @SupunWijerathne If you only need one method of the facade but the facade offers i.e. 12 methods it violates the ISP imo. Imagine you need to implement that interface and you only care about 2 methods, because you only need two methods, then it would be strange to throw NotSupportExceptions for the rest of the not used methods (violation of LSP). – Rookian Aug 31 '16 at 10:44
  • @Rookian I think your opinion is wrong about ISP and LSP. ISP just states program to interface rather implementation. LSP states that any interface 'implementing' should not have excess options which are not fits for the classes that are going to implement it. ex: Circle-elipse problem https://en.wikipedia.org/wiki/Circle-ellipse_problem . In this case the client is not implementing(inheriting) the facade. right? Any way I definitely agree with your last idea 'A facade tends to be the opposite big and not stable'. It's all about what the priority is. :) – Supun Wijerathne Aug 31 '16 at 11:25
  • @SupunWijerathne Sry, but you mix up some of the principles. "The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use." What you mean is the dependency inversion principle. See also http://stackoverflow.com/a/11319026/175399. – Rookian Sep 05 '16 at 08:10
  • @Rookian in simple direct English meaning, Interface Segregation -> Segregate(separate) the interface -> i.e. Abstract out any interface you find before doing any specific implementation. – Supun Wijerathne Sep 12 '16 at 15:35

2 Answers2

7

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.

Supun Wijerathne
  • 11,964
  • 10
  • 61
  • 87
0

You can find it out in this post.

akbar
  • 625
  • 6
  • 12