Комментарии 9
И ни одного коммента.
Видимо не один я добавил в закладки, но оставил на потом, потому что такой объем за раз, конечно, осилить нереально.
Лично для меня было бы проще, если бы это была серия статей.
"Service Locator был достаточно популярным, но у него есть свои минусы, из-за чего впоследствии он стал анти-паттерном. Главной проблемой стало то, что вместо зависимости от конкретного класса мы во всем приложении начинаем зависеть от Service Locator и получаем единую точку отказа." ©
"Интересная особенность: во внутренней реализации вендорских библиотек всегда используется Service Locator." (с)
Интересный вывод — в каждом проекте, использующем Dependency Injection, используется анти-паттерн.
Может хватит уже называть "анти-паттерном" подход, который используется в каждом современном проекте, пусть и не напрямую? Service Locator — это ступень на пути эволюции принципов разработки ПО и у него всё ещё есть область применения (например, "во внутренней реализации вендорских библиотек").
P.S.
Сама статья интересная, вынес в закладки.
Важно отметить, что при взгляде только на статическую структуру DI-контейнерВзял отсюда Марк Симан, Стивен Ван Дерсен «Внедрение зависимостей на платформе .Net» ISBN 978-5-4461-1166-4. Почитайте всё очень хорошо разжёвано.
будет похож на локатор сервисов. Отличие едва уловимое и заключается не в меха-
низмах реализации, а в способе использования. По сути, для разрешения полного
графа объектов из корня композиции правильно будет воспользоваться запросом
контейнера или локатора. Запрос с целью получения детализированных сервисов
не из корня композиции, а из каких-либо других мест приводит к возникновению
антипаттерна «Локатор сервисов».
Ну а я о чём? Вот здесь (корень композиции) это допустимо, а вот здесь (всё остальное) — "антипаттерн". ОК, я не против употребления слова "антипаттерн" по отношению к "Сервис Локатору", если каждый раз в скобочках будут давать ссылку на допустимую область применения. Написал "антипаттерн" и рядом — "за исключением корня композиции".
Хорошая статья, в одном месте объясняет мелкие различия в популярных словах.
Мне понравилось, сохранил.
Хорошее саммари.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Мне понравилось как в книге "Чистая архитектура" у Роберта Мартина ещё детально описано почему именно так:
Зависимости всегда направлены в сторону большей устойчивости. Компоненты, с трудом поддающиеся изменениям не должны зависеть от любых изменчивых компонент. Нестабильный всегда зависит от стабильного, но не наоборот. При этом, устойчивость компонента пропорциональна его абстрактности. Неустойчивый компонент всегда должен быть конкретным. Устойчивый - абстрактным. В итоге, зависимости будут идти в сторону абстрактности (имеется ввиду направление зависимости, а не направление контроля, само собой).
В начале 90-х разработчики Java приняли решение отказаться от полноценного обмена сообщениями между объектами, заменив его "концепцией «отправка сообщения как вызов метода».
В тот момент такое упрощение давало существенный выигрыш в производительности. Средний PC имел 1 МегаБайт оперативной памяти и 25 МГц тактовую частоту. Ни о какой многоядерности и речи не шло.
Но годы идут, вычислительная мощность даже среднего устройства существенно возросла, сложность разрабатываемых систем возросла на порядки, а инструменты разработки остались прежними.
Упрощение концепции, являвшееся в тот момент разумным компромиссом, сейчас стало существенным ограничением, заставляющим разработчиков придумывать "костыли" в виде различных Dependency Injection и др. "инженерные практики". А ведь Low Coupling в виде коммуникации только через сообщения была в основе концепции ООП (The original conception of it had the following parts. 1) I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages —Alan Kay)
Сконструировать У-2 можно было с помощью рейсшины, лекал, ватмана и карандаша. Но современный airbus или boeing так не сделаешь. Нужны компьютеры и программы на всех этапах. Днепрогэс построили лопатами и тачками. Но сколько не удлиняй ручки тачки и не наращивай борта, «Бурдж-Хали́фа» не построишь.
Инструменты должны соответсвовать сложности и на Software Engineering это правило тоже распространяется, хотя заслуги Левши, подковавшего блоху, никто не умаляет.
Dependency Injection в мире Software Engineering