DesignPatternsBook
DesignPatternsBook copied to clipboard
SergeyTeplyakov
[Part2, Ch1] DIP & dependencies count
Слишком большое число зависимостей класса говорит о проблемах в его дизайне.
Понимание этого принципа, ко мне пришло, после прочтения книги Марка Симанса (хотя похоже он позаимствовал некоторые идеи у Физерса). Для меня этот принцип говорит о том, что мы должны анализировать не количество а качество (изменчивость) зависимостей. Необходимо спрятать наиболее подверженные изменениям зависимости за абстрактным классом/интерфейсом. В настоящее время принцип был расширен до управления зависимостями. Т.е. мы должны подумать кто должен управлять временем жизни и определиться с местом создания зависимостей.
Про изменчивые зависимости чего-то будет в главах по принципам. Так что я не уверен, что во введении стоит уделять этому больше внимания. Как думаешь?
Я бы наверное убрал часть которая повествует о количестве зависимостей:
Слишком большое число зависимостей класса говорит о проблемах в его дизайне. Возможно класс делает слишком многое, или же текущий класс неудачно спроектирован, что приводит к необходимости дергания по одному методу у слишком большого числа зависимостей.
и оставить эту часть:
Любой объектный дизайн представляет собой некоторый граф взаимодействующих объектов, при этом некоторые зависимости являются частью реализации и должны создаваться напрямую, а некоторые – передаваться ему извне. Данный принцип говорит о необходимости выделения и передачи наиболее ключевых зависимостей через аргументы конструктора, что позволяет перенести проблемы по созданию и выбору конкретного типа "внешнего поведения" на более верхний уровень.
Поскольку это введение, то здесь вполне нормально допускать некоторые вольности. Ведь в любом случае, если число исходящих связей класса больше определенного предела (скажем 5-7), то с дизайном все равно какая-то байда, не зависимо от того, являются ли внешние зависимсости стабильными или нет. Если класс сидит как паук в паутине, то это плохо, даже если паутина - неизменяемая с точки зрения ФП техник.
Ну этим пауком может быть фасад или апликейшн ;) Я согласен, что большое количество зависимостей, это может быть сигналом к действию, но я не думаю, что DIP имеет к этому отношение.
Да, кстати, я большое число зависимостей не считаю проблемой с DIP, а просто общей проблемой неудачного дизайна.
Причин может быть две: во-первых, класс может тупо делать слишком многое (он и в базу ходит, и с пользователем общается и крестиком вышивает). Во-вторых, зависимости могут быть неудачно спроектированы: просто выбрана неверная проекция: методы сгруппированы таким образом, что всем нужны несколько зависимостей. Вот пример: DAL (обильный) можно разбивать таким образом, чтобы отдельные репозитории отвечали за отдельный аспект (CRUD для Employee, CRUD для reports etc), а можно, чтобы каждый из них отвечал за отдельную операцию: чтение, обновление или удаление. Сказать, какая проекция будет лучше - сложно. Все сильно зависит от потребностей приложения. Но если выбрать неудачную проекцию, то получится, что всем клиентам DAL-а понадобятся практически все репозитории, поэтому каждая вью-моделька будет тянуть IEmployeeRepository, IReportsRepository, ISomethingElseRepository. Т.е. все зависимости, вроде бы, выделены правильно, но проблема в том, что сущности выделены неудачно!