Site icon AppTractor

Инъекция зависимостей или локатор служб?

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

Инъекция зависимостей

В схеме Dependency Injection, например в Dagger/Hilt, вы предоставляете свои зависимости в граф, а во время компиляции генерируется логика создания объекта. Этот шаг очень важен, поскольку в этот момент вы узнаете, не забыли ли вы предоставить зависимость, и можете быстро устранить ошибку. Это означает, что во время выполнения программы не произойдет неожиданного сбоя из-за того, что не удалось разрешить зависимость.

Локатор служб

В схеме Service Location, подобной Koin, вы предоставляете свои зависимости, а во время выполнения они помещаются в контейнер инверсии управления (IoC-контейнер). Затем вы запрашиваете объекты из IoC-контейнера по мере необходимости. Из-за разрешения во время выполнения не гарантируется, что запрашиваемый объект будет существовать в контейнере, что может привести к сбоям во время выполнения. Кроме того, в рамках фреймворка Service Location объекты должны создаваться и храниться в контейнере, что может привести к дополнительным накладным расходам, если нет механизма ленивой загрузки или кэширования экземпляров.

Заключение

По моему опыту, компромиссы, связанные с простотой и легкостью настройки Service Location, редко окупаются в долгосрочной перспективе по сравнению с безопасностью Dependency Injection на этапе компиляции. Нет более неприятного ощущения, чем падение приложения из-за того, что вы предположили, что объект должен быть там, а его там не оказалось.

Примечания

Источник

Exit mobile version