А теперь ответьте мне на мой вопрос: Если вы вытащили кишки класса наружу, и свалили мне на голову свою БД, накой чорт мне тогда может быть нужен класс BookStorage?
Так ведь он нужен для операций с хранилищем. Ну добавим в метод insert() еще пару строк, а потом добавим еще метод remove(). И что, ты каждый раз теперь будешь дублировать операции из insert() и remove(), раз смысл в BookStorage пропал? BookStorage теперь содержит только операции с хранилищем и избавлен от разруливания зависимостей при создании этого хранилища.
Да и почему свалили тебе на голову БД, ведь вытаскивание этих "кишок" всего лишь подготовка класса для работы с IoC контейнером. Эти "кишки" затем опять будут спрятаны, но уже в другом месте.
Вот еще одно определение для DI:
Внедрение зависимостей — паттерн проектирования, основная задача которого — отделить поведения объекта от управления его зависимостями
Еще раз повторю, эти "кишки" достаются не тебе, а перемещаются в другую сущность.
Но если уж вашей милостью мне все равно пришлось иметь дело с бд, тогда накой чорт мне нужен BookStorage?
ведь все, что он может сделать используя бд, и я сам могу сделать используя бд.
Да, можешь и сам, но если тебе понадобится сделать это в нескольких местах, ты все-равно создашь отдельных класс, чтобы не дублировать код.
Вот за этим он и нужен, инкапсулирует операции над хранилищем. Да, в этом примере из двух классов все это не имеет особого смысла, но ведь это только пример, чтобы показать принцип.
В отличие от "внедрения зависимостей", адепты которой сами толком не могут по простому ответить на вопрос - зачем это нужно.
Так ведь в который раз уже: уменьшить связанность между компонентами, избавление от ручного создания объектов; отделение поведения объекта от управления его зависимостями.
Кстати, в чем вы видите разницу между стратегиями и этим DI?
Все же DI и компания ближе к фабрикам, чем к стратегиям.
Я имел возможность убедиться в этом на собственной шкуре - когда однажды понял, что совершенно напрасно потратил время и усилия на поддержку "тонких настроек", которыми никто никогда так и не воспользовался, потому что "это гимморно слишком, проще взять другой механизм, который из коробки лучше отвечает требованиям".
Ну вот был у тебя неудачный опыт с избыточными сущностями, причем не с DI/IoC, а все-равно это анти-паттерн, причем потом еще оказывается, что
Что касается DI - я так и не понял, что это такое, и зачем оно нужно.
Откуда взялось стойкое мнение, про абсолютную вредность этого паттерна, если нет ясного понимания? Меня вот это удивляет.
Верес тоже хорош, привел ссылку и тут же говорит, что не понял, что написано. Так зачем было вообще ее постить? Увидел слова "внедрение" и "зависомость"? Так может там описание порнофильма с наркоманами было, а не про DI?
Зачем вводить людей в заблуждение. Это вполне нормальный прием, который удачно можно использовать.
Это не вызывает вопросов, но причем здесь "инжекция" - хз.
Ну как причем, показан прием инъекции через конструктор.
Тогда чем плохи стандартные подходы - виртуальный базовый класс и/или фабрика?
Все, что связано с DI/IoC, относится не к изменению поведения, а к переносу ответственности за создание объектов в другое место. Фабрика здесь вполне подойдет, но об отличии фабрики от ID я выше приводил цитату с SO.
Может быть я что-то не так объяснил, раз народ до сих пор чешет репу, зачем это нужно (а может вам оно и не нужно?). Ну давайте вот еще один пример, уже из документации Guice (java):
https://github.com/google/guice/wiki/Motivation (англ).
PS я не призываю никого использовать этот паттерн, и не доказываю, что это какая-то панацея от всех бед, что он лучше других подходов. Единственное, что хочется донести, что его называют бесполезным и опасным совсем не заслуженно.
