БД изначально была деталью реализации механизма, которая специально для того и была инкапсулирована, что бы мы (пользователи) могли выполнять операции над книжкой, и ни о чем не париться.
Что-то ты напридумывал. Судя по коду, инкапсулирована она была для получения доступа к ней же из BookStorage, чтобы записать туда book. Откуда ты взял все остальное не ясно.
Вы взяли и вытащили кишки наружу. Теперь пользователям самим нужно геммороиться по созданию объекта БД, его и его настройке.
Это не кишки, вот если бы я вытащил наружу сожедримое метода insert(), то да. Создание Database не относится к внутренностям класса BookStorage, это не его ответственность, о чем, кстати, говорит само название класса BookStorage - Storage. Где тут про базы данных? Вот по этому-то и вытаскивают Database, чтобы избавить BookStorage от не относящихся к нему операций (создание Database).
Принцип действия этого анти-паттерна можно выразить словами: давайте нарушим инкапсуляции, и вытащим кишки класса наружу. И предложим пользователям самостоятельно поиметь геммор со всем этим.
Инкапсуляция тут совсем не нарушается - данные остаются с методами, их обрабатывающими (метод insert), а вот создание связанных сущностей выносится во вне. Причем это делается с определенной целью, а не посто ради создания дополнительных сущностей. Это не ООП ради ООП.
Твоя главная ошибка здесь, что ты считаешь бд и ее создание неотъемлемой частью класса BookStorage. Это первая причина разногласий.
А на самом деле мы провели рефакторинг и оптимизировали класс BookStorage, оставив ему только функции, связанные с манипуляциями хранилищем.
А для оставшегося функционала (создание и внедрение в BookStorage) у нас есть несколько вариантов:
1. Отдаем на откуп пользователя - об этом ты писал. Заметь, до этого момента
нет ничего противозаконного, никаких анти-паттернов. Просто ты не видишь
преимуществ "отрефакторенного" BookStorage, или не хочешь видить, тк уверен, что
все это какой-то мифический анти-паттерн.
Тут мы сами создаем и сами внедряем бд в BookStorage.
Некоторые преимущества см. в пункте 2.
2. Помещаем создание в фабрику или что-то похожее - теперь создает не пользователь,
а фабрика, но внедряет все еще пользователь. Тут создается "лишняя" сущность. Будем считать
это отрицательным моментом, но оно приносит ряд преимуществ: легче сопровождать
BookStorage, легче заменять одни части на другие, лугче расширять код,
повторное исользование компонентов становится легче.
Получается для тебя это куча бесполезной ботвы, да еще и вредной. Единственное, что
можно вытащить из твоей цитаты, так это "усложнение конструкции", да и то спорное.
3. Отдаем на откуп IoC-контейнера - создание и внедрение происходит автоматически.
4. Что-нибудь еще, выходящее за рамки поста.
класс BookStorage в этом случае вообще становится не нужным.
Это не так, потому что BookStorage продолжает выполнять свою функцию - сохраняет данные в хранилище.
резюме:
1. То, что мы вытащили, не является "кишками" BookStorage, просто этого там не должно быть (в данном случае).
2. Это совсем не бесполезное, и даже полезное (в данном случае), потому что уже само по себе приносит ряд улучшений.
3. Это не ООП ради ООП, все это для создания меньшей связанности между классами. Конечно отвязать все отовсюду это перебор, и уже будет раздуванием архитектуры, но совсем не в нашем случае.
4. Ты выдираешь фразы из контекста.
Вот мы мы вытащили создание бд из класса и поместили в еще один класс. Теперь у нас 2 класса.
Ты берешь эти 2 факта (вытащили что-то и добавили еще один класс) и на нах строишь свою логику, совсем не учитывая, зачем это было сделано.
Конечно, в таком случае, все эти дейтвия будут казаться странными.
Разберись, для чего это было сделано.
А я еще раз повторю, что это все в основном для уменьшения связанности компонентов. А потом поищи, зачем компоненты стремятся отвязать друг от друга.
Если ты пишешь hello-world, то DI/IoC для тебя будет излишним, и ты получишь свое "раздувание оо-архитектуры кучей ненужных и избыточных сущностей".
Хотя даже в маленьких проектах ты не желая того делаешь инверсию управления, выделяя интерфейс из класса (а это потому-что паттерны проектирования всего лишь систематизация общеупотребляемых практик).
Ну а еще есть не hello-world проекты, где это успешно можно применить.
в чем смысл? В чем плюс?
Еще раз, слабая связанность, избавление от ручного создания объектов.
внедрения прослойки (опять таки внедрённой только ради внедрения)
Прослойка внедряется для того, чтобы отвязать 2 сущности друго от друга и убрать из них лишнюю нагрузку в виде создания определенных объектов.
класс прослойка, который знает всё о классах машины, колёс, знает принципы их взаимодействия
Что за панический страх перед прослойками?
Я тебе по секрету скажу, что есть опять же паттерн фасад. И он специально нужен, чтобы знать обо всех, и он - прослойка.
Вот почему класс-прослойка у тебя вызывает вопросы, а прослойка между монитором и стулом не вызывает?
Почему такая избирательность.
