-
-
Notifications
You must be signed in to change notification settings - Fork 59
Inversion of control
IOC - техника подмены деталей целого
di на service locator не годится для многопоточности и асинхронности, т.к. глобал по-определению
di через мерж определенного аргумента-объекта из поддерева функций не годится из-за конфликтов имен свойств, прогрессивного усложнения интерфейса контекста при его сборке от деталей к целому, сложности локализации ошибок в ts при конфликтах типов (пока правда у меня), сложности мемоизации (приходится часто делать spread), склонности к загрязнению переменной-контекста, когда контекст родителя содержит зависимости только для родителя, детьми они не используются, но прокидываются им
di на AOP и конфигурациях (ninject, inversify, angulardi) не годится из-за:
Громоздкого и сложного описания зависимостей с целью их создания и контроля их времени жизни.
Необходимости ручного задания мета-инфы для зависимостей не-классов или интерфейсов без меты, т.к. в ts слабые возможности рефлексии.
Сложности контроля создания объекта: в angulardi для этого целый набор декларативных конструкций (Injectable, Directive, NgModule, Optional, Self, SkipSelf, providers, viewProviders, provideIn), хоть проще это делать императивно.
Проблемы с наследованием конфигураций
Жесткие зависимости по-умолчанию, т.к. нет дефолтной реализации зависимости, что усложняет создание объекта в отрыве от DI-фабрики
di через ambient context. Марк Симан, подразумевает под ac конкретный сервис, а не реестр сервисов. Использование его ac в сложных программах, также как и в di через мерж, черевато транзитивными зависимостями ("Потенциально это может заставить вас писать много кода с дополнительным параметром TimeProvider, потому что вы не знаете, когда он сможет вам понадобиться").
Почему-то он не смог сложить (или я не нашел) ambient context + service locator. Еще Марк, ссылаясь на cross-cutting concern и DDD Эрика Эванса, считает, что неявновть ac (отсутствие в конструкторе точек расширения) является недостатком. Кстати, по примеру "Модификация времени" видно, что Марк мыслит категориями ООП без реактивности: "Одна из многих опасностей Ambient Context заключается в том, что как только он назначен, он остается одинаковым, пока не будут изменен снова, но в связи с его неявной природой, об этом можно легко забыть". Проблема с инвалидацией реактивного кэша отсутствует в данном случае.
В mol используется context locator, у которого с точки зрения апологетов tdd, есть один недостаток - не представленность зависимотей в конструкторе класса (Симан говорит про неявность) и необходимость тащить этот самый locator из класса в класс.
Этот "недостаток" вытекает из потребности мокать все зависимости класса при тестировании, что нужно для tdd, когда класс тестируется изолированно от всего. Есть сомнения в таком подходе, как альтернативу можно попробовать компонентное тестирование.