Отличный вопрос.
Во-первых, имейте в виду, что это упрощенный пример в книге. Читатель должен немного углубиться в это и представить более сложные сценарии. Во всех этих сценариях представьте, что вы не единственный разработчик в команде; вместо этого вы работаете в большой команде, и общение между разработчиками часто принимает форму согласования интерфейсов классов , т.е. API, открытых методов, открытых атрибутов, схем баз данных. Кроме того, вам часто придется беспокоиться об откатах, обратной совместимости и синхронизации выпусков и развертываний.
Предположим, например, что вы хотите обменять базу данных, скажем, с MySQL на PostgreSQL. С помощью SRP вы переопределите CarDAO, измените любой используемый для диалекта SQL и оставите логику Car без изменений. Однако вам, возможно, придется внести небольшое изменение, возможно, в конфигурацию, чтобы указать Car использовать новый PostgreSQL DAO. Разумная структура DI сделает это простым.
Предположим, в другом примере, что вы хотите делегировать CarDAO другому разработчику для интеграции с memcached, так что чтение, хотя и в конечном итоге непротиворечивое, происходит быстро. Опять же, этому разработчику не нужно ничего знать о бизнес-логике в Car. Вместо этого им нужно работать только за методами CRUD CarDAO и, возможно, объявить еще несколько методов в API CarDAO с различными гарантиями согласованности.
Предположим, что в еще одном примере ваша команда нанимает инженера базы данных, специализирующегося на соблюдении законодательства. При подготовке к предстоящему IPO инженеру базы данных поручено вести журнал аудита всех изменений по всем таблицам в 35 базах данных компании. С SRP нашему бесстрашному администратору базы данных не нужно было бы беспокоиться о какой-либо бизнес-логике , использующей любую из наших таблиц; вместо этого их магию отслеживания мутаций можно ловко внедрить в DAO, используя декораторы или другие методы программирования аспектов. (Кстати, это можно сделать и с другой стороны интерфейса SQL.)
Хорошо, последний вопрос. Предположим теперь, что в команду входит системный инженер, которому поручено распределять эти данные по нескольким регионам (центрам обработки данных) в AWS. Этот инженер может пойти дальше SRP и добавить компонент, единственная роль которого заключается в том, чтобы сообщать нам для каждого идентификатора домашний регион каждой сущности. Каждый раз, когда мы выполняем межрегиональное чтение, новый компонент увеличивает счетчик; каждую неделю автоматизированный инструмент переносит данные, часто считываемые между регионами, в новый домашний регион, чтобы уменьшить задержку.
Теперь давайте продолжим наше воображение и предположим, что бизнес процветает - внезапно вы работаете в компании из списка Fortune 500 с несколькими отделами, охватывающими несколько стран. Бизнес-аналитики из финансового департамента хотят использовать вашу таблицу для составления квартального роста продаж автомобилей в своих отчетах для инвесторов после IPO. Вместо предоставления им доступа к Car (поскольку логика, используемая для создания отчетов, может отличаться от логики, используемой для подготовки данных к визуализации в веб-интерфейсе), вы могли бы потенциально создать интерфейс только для чтения для CarDAO с краткий список тщательно отобранных общедоступных атрибутов, которые вы теперь должны поддерживать за пределами отдела. Не дай Бог, вы должны переименовать один из этих атрибутов: будьте готовы к 3-месячному плану заката и множеству грустных информационных панелей и ночных эскалаций. (И, пожалуйста, не предоставляйте им прямой доступ к реальной таблице SQL, поскольку подразумевается, что вся таблица представляет собой открытый интерфейс .) К сожалению, мои шрамы могут отображаться.
Следствие состоит в том, что если вам нужно изменить бизнес-логику в Car (скажем, добавить метод, который вычисляет более низкую продажную цену каждой Tesla после смущающего отзыва), вы бы не t коснитесь CarDAO, поскольку if car.brand == 'Tesla; price = price * 0.6 не имеет ничего общего с доступом к данным.
Дополнительное чтение: CQRS