Как стать автором
Обновить

Комментарии 8

И ни одного коммента.
Видимо не один я добавил в закладки, но оставил на потом, потому что такой объем за раз, конечно, осилить нереально.


Лично для меня было бы проще, если бы это была серия статей.

Просто это общеизвестные факты, которые изложены в любой современной книжке по разработке. Чего тут коментировать ?)

"Service Locator был достаточно популярным, но у него есть свои минусы, из-за чего впоследствии он стал анти-паттерном. Главной проблемой стало то, что вместо зависимости от конкретного класса мы во всем приложении начинаем зависеть от Service Locator и получаем единую точку отказа." ©


"Интересная особенность: во внутренней реализации вендорских библиотек всегда используется Service Locator." (с)


Интересный вывод — в каждом проекте, использующем Dependency Injection, используется анти-паттерн.


Может хватит уже называть "анти-паттерном" подход, который используется в каждом современном проекте, пусть и не напрямую? Service Locator — это ступень на пути эволюции принципов разработки ПО и у него всё ещё есть область применения (например, "во внутренней реализации вендорских библиотек").


P.S.
Сама статья интересная, вынес в закладки.

Важно отметить, что при взгляде только на статическую структуру DI-контейнер
будет похож на локатор сервисов. Отличие едва уловимое и заключается не в меха-
низмах реализации, а в способе использования. По сути, для разрешения полного
графа объектов из корня композиции правильно будет воспользоваться запросом
контейнера или локатора. Запрос с целью получения детализированных сервисов
не из корня композиции, а из каких-либо других мест приводит к возникновению
антипаттерна «Локатор сервисов».
Взял отсюда Марк Симан, Стивен Ван Дерсен «Внедрение зависимостей на платформе .Net» ISBN 978-5-4461-1166-4. Почитайте всё очень хорошо разжёвано.

Ну а я о чём? Вот здесь (корень композиции) это допустимо, а вот здесь (всё остальное) — "антипаттерн". ОК, я не против употребления слова "антипаттерн" по отношению к "Сервис Локатору", если каждый раз в скобочках будут давать ссылку на допустимую область применения. Написал "антипаттерн" и рядом — "за исключением корня композиции".

Просто постоянно идёт подмена понятий «реализация» и «использование»:
Реализовывать Service Locator — нормально.
Использовать эту реализацию каждый раз, когда нужен класс — плохо.

Создавать ЯП — нормально, пытаться его запихнуть во все задачи — плохо. Тут что-то похожее.

Хорошая статья, в одном месте объясняет мелкие различия в популярных словах.

Мне понравилось, сохранил.

Хорошее саммари.

Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Мне понравилось как в книге "Чистая архитектура" у Роберта Мартина ещё детально описано почему именно так:

Зависимости всегда направлены в сторону большей устойчивости. Компоненты, с трудом поддающиеся изменениям не должны зависеть от любых изменчивых компонент. Нестабильный всегда зависит от стабильного, но не наоборот. При этом, устойчивость компонента пропорциональна его абстрактности. Неустойчивый компонент всегда должен быть конкретным. Устойчивый - абстрактным. В итоге, зависимости будут идти в сторону абстрактности (имеется ввиду направление зависимости, а не направление контроля, само собой).

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.