Facade pattern vs. SRP

Question

In the classic Facade pattern, a single object usually provides a simplified interface to something more complex.

As the Gang-of-Four put it (as close to "official" as it gets...):

Facade (185) 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.

and

...a facade merely abstracts the interface to subsystem objects to make them easier to use; it doesn't define any new functionality, and subsystem classes don't know about it.

Or, as Unmesh puts it in https://stackoverflow.com/a/5242476 :

A Facade shields the user from the complex details of the system and provides them with a simplified view of it which is easy to use. It also decouples the code that uses the system from the details of the subsystems, making it easier to modify the system later.

The Single Responsibility Principle advises us that

a class or module should have one, and only one, reason to change.

Per Uncle Bob (http://en.m.wikipedia.org/wiki/Single_responsibility_principle)

Given that a Facade, by design, shields a user from a multitude of "reasons to change", how can these two ideas work together? Doesn't a Facade have as many reasons to change as the number of subsystems on which its implementation depends?

Answer 1

Basically, if your Facade class implements Dependency Inversion principle (it depends upon abstractions, but not upon concrete realizations), you will don't have a need to modify it in the future.

Exceptions - if there is a bug or if you need to change Facade's business logic (e.g., interaction between those subsystems that it encapsulates). But this is not SRP violation.

Btw, seems like it implicitly mentioned in the quote:

Facade (185) Provide a unified interface to a set of interfaces in a subsystem

Answer 2

First of all,

Patterns and principles - are two distinct things. A pattern is a proven solution to a problem, while a principle is nothing more than just a guideline.

So, comparing them would be pointless, especially since they complete each other in most cases.

As for SRP's definition, "One reason to change" can be explained easily:

Image if you build a car's object, that would consist of engine, type and things like that. So the construction of that object would look like as:

car = new Car(new Engine(), new Type());

So what if you want to replace an engine of that car? Then you'd simply replace Engine's instance. That's one reason to change, since you don't touch other parts of it.

As for facades, the definition you've provided is way too general. A facade is just another way of wrapping things that might be not available under some environments. They simply make sure, that your thing would work in all environments. For example, there's a very known example of event-listeners in JavaScript:

function click(object, handler){
   if (object.addEventListener != undefined){
     // For major browsers
     object.addEventListener(....);
   } else if (object.attachEvent != undefined){
     // For IE < 7
     object.attachEvent(...)
   } else {
     object.click = handler;
   }
}