Серия идет в таком духе, что из статьи в статью переносятся основные мысли с добавлением нового. Да, автор снова перечисляет плюсы DI и добавляет к этому еще плюс от применения DI-контейнера (меньше перенос зависимостей). Думаю, такой подход оправдан и полезен для тех, кто с темой только начинает знакомиться.
Куча ненужных терминов, рассчитанных на людей, которые и так давно в теме.
Я немного удивлен. Думаю, здесь терминов не больше десятка. И избыточных из них может быть, разве «коллаборатор». Какие термины Вы считаете лишними?
В матане за таким стилем стоит хотя бы идея — формальная корректность от аксиом и вот это всё — то здесь тупо понты, «смотрите какие умные слова я знаю».
Думаю, это хороший повод для дискуссии. Допустим, в начале проекта мы делаем DI вручную. В какой-то момент код, занимающийся созданием объектов, станет настолько обширным, что работать с проектом станет неудобно. Тогда мы встанем перед выбором: продолжать накручивать самодельные несистематические костыли или использовать для управления зависимостями контейнер.
Допустим, мы выбрали контейнер. И даже то, что мы получим зависимость от контейнера, будет плюсом. Даже двумя (как минимум). Мы получим: 1) единый «центр управления» — контейнер упростит создание экземпляров и их внедрение (это очевидное преимущество), 2) мы будем использовать «хорошую» зависимость.
Под «хорошей» зависимостью я в данном случае понимаю то, что контейнер поставляется в виде внешней библиотеки. Код контейнера, очень вероятно, будет построен по принципам открытого ПО. Это точно верно для всех контейнеров, упомянутых в статье. Это значит, что этот код будет доступен и многократно перепроверен сообществом.
Привет, tehreh1uneh! Я только что серфил по Хабру, чтобы найти пример для оформления серии статей и нашел твою серию. Начал читать потому, что сейчас сам исследую тему IoC, DI, контейнеры. И что-то мне показалось до боли знакомым.
Очень похоже, что автор оригинала твоей статьи читал оригинал статьи Understanding Dependencies от 2014 года, которую я перевел для Хабра. Некоторые моменты просто один в один. И это не плохо. Мне тоже она показалось ценной. Если ты не против, я оставлю здесь ссылку на свой перевод, чтобы читатели смогли более полно ознакомиться с разновидностями зависимостей, часть из которых здесь не приведена. Understanding dependencies (или Понимая зависимости).
Пример ухода от зависимости от класса путем перехода к зависимости от интерфейса из статьи Jakob Jenkov Understanding Dependencies (в моем переводе).
Зависимость метода от класса:
public byte[] readFileContents(String fileName){
//open the file and return the contents as a byte array.
}
Зависимость метода от интерфейса:
public byte[] readFileContents(CharSequence fileName){
//open the file and return the contents as a byte array.
}
Если заменить Init на Foo, будет обычное внедрение через конструктор. Использовать отдельный метод для инициализации здесь и в общем случае излишне (кроме специальных случаев, подобных примеру с Unity3D ). В конструктор можно точно так же заинжектить интерфейс, как и в метод. То есть суть interface injection — только в том, что в метод/сеттер передается не реализация, а интерфейс. Таким образом, мы уходим от зависимости от конкретной реализации. Больше ничего.
Спасибо. Пробовал это сделать, кнопка «удалить» не активна. Обратился в поддержку. Оказывается, нельзя удалить черновик статьи, которая уже была опубликована и затем скрыта.
Если писать идеально, то да. Изначально для меня идея перевода включала в себя принцип не делать текст ни лучше, ни хуже, чем он есть на самом деле. Это касается не только основного текста, но и кода тоже. Основную идею статьи код, на мой взгляд, иллюстрирует. Действительно, он не идеален. Однако, автор написал так как он написал. На данный момент я вижу такой выход как сделать апдейт с явным комментарием от переводчика, который явно укажет на недостатки авторского кода. П.С. основное преимущество текстов от Jakob Jenkov — это простота и доходчивость. Давайте вместе отмечать недостатки и делать текст лучше.
Не будем отрицать: принципы ООП, это действительно инкапсуляция, наследование и полиморфизм:). Однако, можно сказать, что все они связаны с управлением зависимостями. Да, есть вариант разрешения зависимостей внутри класса, но это ведет к негативным последствиям, описанным в разделе «почему зависимости плохо». Де-факто такой подход устарел, и ему на смену пришло «внедрение зависимостей». На этой теме сфокусирована еще одна статья от этого автора. Над ее переводом я сейчас работаю. Приглашаю познакомиться с ней, думаю, что там Вы найдете еще интересные доводы в пользу DI.
Если число параметров метода login не будет изменяться в сторону повышения, думаю, лучше оставить строки, как есть. Однако, если число параметров вырастет за 4 (моя личная граница удобства), то объект лучше создать.
Я немного удивлен. Думаю, здесь терминов не больше десятка. И избыточных из них может быть, разве «коллаборатор». Какие термины Вы считаете лишними?
Ок, преамбулу Вы сделали. Давайте к конкретике.
согласен. библиотека не должна зависеть от фреймворков.
Допустим, мы выбрали контейнер. И даже то, что мы получим зависимость от контейнера, будет плюсом. Даже двумя (как минимум). Мы получим: 1) единый «центр управления» — контейнер упростит создание экземпляров и их внедрение (это очевидное преимущество), 2) мы будем использовать «хорошую» зависимость.
Под «хорошей» зависимостью я в данном случае понимаю то, что контейнер поставляется в виде внешней библиотеки. Код контейнера, очень вероятно, будет построен по принципам открытого ПО. Это точно верно для всех контейнеров, упомянутых в статье. Это значит, что этот код будет доступен и многократно перепроверен сообществом.
Очень похоже, что автор оригинала твоей статьи читал оригинал статьи Understanding Dependencies от 2014 года, которую я перевел для Хабра. Некоторые моменты просто один в один. И это не плохо. Мне тоже она показалось ценной. Если ты не против, я оставлю здесь ссылку на свой перевод, чтобы читатели смогли более полно ознакомиться с разновидностями зависимостей, часть из которых здесь не приведена. Understanding dependencies (или Понимая зависимости).
Зависимость метода от класса:
Зависимость метода от интерфейса: