Здравствуйте, Тепляков Сергей Владимирович, Вы писали:

ТСВ>Статья:
ТСВ>Паттерны внедрения зависимостей

Автор(ы): Тепляков Сергей Владимирович
Дата: 23.10.2015
Статья рассказывает о наиболее популярных паттернах внедрения зависимостей, которые будут полезны всем разработчикам, независимо от того, используют они какой-либо контейнер или предпочитают ручную композицию объектов в приложении.

Такой вопрос по ServiceLocator. Почему по-твоему проблема

Самое страшное в Service Locator то, что он дает видимость хорошего дизайна. У нас никто не знает о конкретных классах, все завязаны на интерфейсы, все «нормально» тестируется и «расширяется». Но когда вы попробуете использовать ваш код в другом контексте, или когда кто-то попробует использовать его повторно, вы с ужасом поймете, что у вас есть дикая «логическая» связанность, о которой вы и не подозревали.

относится только к нему и не относится к прочим паттернам?


По-моему, эта проблема общая для любой _динамической_ системы разруливания зависимостей и нюансы конкретной реализации тут мало что решают. Особенно с типовым для биз-логики требованием "настраиваемый объект может _динамически_ создавать другие настраиваемые через DI объекты".

Самое парадоксальное, что я видел — когда локатору прямо противопоставляют IOC фреймворки, хотя у них под капотом по факту всё тот же словарик {тип, метод для получения экземпляра}

P.S. Кстати, в "Смягчаем проблему" не упомянут самый правильный способ — навешивание на ServceLocator extension-методов, которые явно документируют поддерживаемые методы через интеллисенс.