Нарушает ли шаблон Facade SRP?

Сам по себе рисунок фасада не нарушает SRP. Часто узор фасада скрывает сложное взаимодействие между нижележащими объектами. В этом случае «единственная ответственность» фасада заключается в управлении этими взаимодействиями. Пока эти взаимодействия не меняются, у вашего фасада не должно быть причин для изменения. Если взаимодействия становятся действительно сложными, возможно, стоит снова разделить реализацию вашего фасада на несколько объектов.

Если я смотрю на ваши примеры, у меня не создается впечатление, что вы действительно пытаетесь скрыть сложность, поэтому может быть интересно пересмотреть здесь использование шаблона фасада.

Я вижу цель SRP в том, чтобы выявить случаи, когда класс делает слишком много, и где лучшим дизайном было бы иметь несколько классов. Классический пример: класс ReportProducer, который выполняет некоторую работу по сборке данных и еще одну работу по форматированию вывода, вероятно, должно быть два класса: один для сбора, один для форматирования. Среди преимуществ такого подхода — гибкость: мы можем использовать один класс сбора и несколько разных классов форматирования.

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

Каковы причины изменений? В примере с отчетом у нас есть два совершенно разных вида изменений: возможно, откуда поступают данные, или, возможно, изменяется желаемый формат. В вашем примере можно утверждать, что существует также несколько возможных причин: может измениться «форма» заказа, может измениться желаемый интерфейс (например, добавить метод queryCancelledOrders()), серверная часть, для которой вы являетесь Фасадом может измениться. Однако я не считаю, что это признаки того, что вы нарушаете SRP: все они относятся к задаче предоставления интерфейса для манипулирования заказами.

Если бы мы восприняли «единственную причину изменения» буквально, то я не верю, что мы когда-либо смогли бы написать какой-либо класс. У нас всегда есть интерфейс и реализация, а также обычно какие-то зависимые классы. Любой из них может измениться, поэтому у нас всегда есть по крайней мере две, а возможно, и три причины для изменений.

Вместо этого подумайте о том, «что это за классы ответственности?» можете ли вы выразить это в предложении, не используя такие слова, как «И». Плохо: собрать данные и отформатировать отчет.

SRP касается изменений в деталях реализации одной ответственности, которые могут привести к изменению класса, даже если эта ответственность является лишь небольшой частью класса.

Фасад не может нарушить SRP таким точным и более серьезным образом, потому что это лишь поверхностное отражение — он не будет меняться каждый раз, когда меняется внутреннее устройство одной из операций. Оно может измениться, когда изменится название одной из операций, что вызывает некоторую нестабильность, но ничего страшного, или когда операция, которую мы хотим отразить через Фасад, будет удалена или добавлена ​​— но здесь есть еще кое-что. делать с тем, что Фасад хочет выставить напоказ, что является фактически его фактической ответственностью.

Чаще всего я использую Facade, когда хочу, чтобы сторонний компонент использовался моим кодом через единую точку входа. Примером этого является Уровень защиты от коррупции узор. Однако я обычно дважды думаю о создании Фасадов для своего собственного кода, потому что вы можете быть легко покорены его удобством, и это может помешать вам действительно думать о зависимостях между объектами.