Рисунок фасада и SRP

По сути, если ваш класс Facade реализует принцип инверсии зависимостей (он зависит от абстракций, а не от конкретных реализаций), вам не нужно будет изменять его в будущее.

Исключения — если есть ошибка или если вам нужно изменить бизнес-логику Фасада (например, взаимодействие между теми подсистемами, которые он инкапсулирует). Но это не нарушение SRP.

Кстати, кажется, что это неявно упоминается в цитате:

Фасад (185) Предоставляет унифицированный интерфейс для набора интерфейсов в подсистеме.

Прежде всего,

Шаблоны и принципы - разные вещи. Шаблон — это проверенное решение проблемы, а принцип — не более чем руководство.

Так что сравнивать их было бы бессмысленно, тем более, что в большинстве случаев они дополняют друг друга.

Что касается определения SRP, «одна причина для изменения» может быть легко объяснена:

Представьте, если вы создадите объект автомобиля, который будет состоять из двигателя, типа и тому подобного. Таким образом, конструкция этого объекта будет выглядеть так:

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

Так что, если вы хотите заменить двигатель этой машины? Тогда вы просто замените экземпляр Engine. Это одна из причин для изменения, поскольку вы не трогаете другие его части.

Что касается фасадов, то данное вами определение слишком общее. Фасад — это просто еще один способ упаковать вещи, которые могут быть недоступны в некоторых средах. Они просто следят за тем, чтобы ваша вещь работала во всех средах. Например, есть очень известный пример слушателей событий в 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;
   }
}