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?

What would the multitude of reasons be to change a facade? – PeeHaa Apr 16 '15 at 08:25 — PeeHaa, Apr 16 '15 at 08:25
will clarify in the post – goofballLogic Apr 16 '15 at 08:26 — goofballLogic, Apr 16 '15 at 08:26

score 5 · Answer 1 · answered Apr 21 '15 at 12:00

5

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

answered Apr 21 '15 at 12:00

Witcher

1,070
2
15
38

yeah that kind of makes sense except that part of the facade's task is to shield consumers from changes in the underlying systems. If that's worth doing, doesn't it imply that those systems are complex enough that even their interfaces will change as they are versioned? – goofballLogic Apr 21 '15 at 12:04
I got what you mean. Yes, if you have to update interface of a specific subsystem - it means that you have violated Interface Segregation Principle for that interface. And don't forget about Open-Closed principle - it's better to extend existing interface/class, than to update it internal content. Seems like you have to be aware of all SOLID principles while constructing new class:) – Witcher Apr 21 '15 at 12:13

score 1 · Answer 2 · answered Apr 16 '15 at 08:58

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;
   }
}

Updating my question to reflect the "official" GoF definition of facade — goofballLogic, Apr 16 '15 at 10:28
Your example facade doesn't really fit the classical definition of the facade pattern, at least in OO circles. — goofballLogic, Apr 16 '15 at 10:34
The definition I described comes from the book by Ross Harmes and Dustin Diaz which is called JavaScript design patterns (Page 141). As for you reflected changes, I'd simply implement an interface for those "facades" and since now the implementation would depend on abstractions and not on concrete implementations, which would solve your problem — Yang, Apr 16 '15 at 11:42
yes, they've adapted the pattern for the javascript world. I think their pattern is well labelled as a "facade" because it wrap access to multiple potential underlying subsystems. However, it's quite different than the classical Facade pattern in which the facade object would contain multiple methods such as this one. It should be noted that even in their tiny "facade", there are at least three potential reasons for change because three different standards are being supported. — goofballLogic, Apr 16 '15 at 12:22

Facade pattern vs. SRP

2 Answers2