Does the Facade pattern violate SRP?

Question

SRP principal say:

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

I have some Facade class as my service layer classes. e.g SaleService, that it provide some methods e.g SaveOrder(), CancelOrder(), CreateOrder(), GetAllOrders(), GetAllPlannedOrders(), ...

I only put them together because of their conceptual relations.
Does using such classes with this methods, that may have more than one reasons to change(), violate SRP? if yes, how can i handle this problem?

Answer 1

The facade pattern does not violate SRP per se. Often the facade pattern hides a complex interaction between underlying objects. In this case the 'single responsibility' for the facade is managing these interactions. As long as these interactions do not change, there should be no reason for your facade to change. If the interactions get really complex, it may be worthwhile to split the implementation of your facade in multiple objects again.

If I look at your examples, I do not get the impression that you are really trying to hide complexity, so it might be interesting to reconsider the use of the facade pattern here.

Answer 2

I see the purpose of SRP being to identify cases where a class is doing too much, where a better design would be to have multiple classes. A classic example: a ReportProducer class, which does some work to assemble the data and some more work to format the output, probably there should be two classes: one for gathering, one for formatting. Amongst the benefits of that approach is flexibility: we can use a single gather class and multiple different formatter classes.

Now your example seems quite reasonable, you have a coherent class, all the methods are related, a user of the class knows that this is the class to go to for Orders. This looks like a single responsibility to me.

What are reasons for change? In the report example we have two completely different kinds of change: perhaps where the data comes from changes, or perhaps the desired format changes. In your example, one could argue that there are also multiple possible reasons: the "shape" of an Order could change, the desired interface could change (eg. add a queryCancelledOrders() method) the back-end that you are a Facade to might change. However I don't believe that these are indications that you violate SRP: they all relate to the task of presenting an interface for manipulating orders.

If we were to take "single reason for change" completely literally then I don't believe we could ever write any class. We always have interface and implementation, and usually also some dependent classes. Any one of those might change, so we always have at least two and probably three reasons for change.

Instead think of "what is this classes responsibility?" can you express it in a sentance without using words such as "AND". Bad: Collect data AND format report.