так говорят меняет
дядюшка Боб против такого
читал, что и компилятор твой класс перекомпилировать будет при любом изменении fileLogger, хоть у тебя ничего и не поменялось (ты же через интерфейс работаешь)
и вот как раз dip будет решением
т.е. здесь dip - в конструкторе тоже интерфейс указывать, а не реализацию
а у нее - чтобы у тебя член класс был с типом интерфейса, а не реализации

про это и вопрос

class Service {
    LoggerInterface logger;

    Service(LoggerInterface logger = new NullLogger()) {
        this.logger = logger
    }
}

вот это про баланс между простотой конфигурации дерева зависимостей и dip. он тут сохраняется

вообще мне казалось, что я про это у Боба и читал, но как спорить с нею стал, найти у Боба не смог, зато нашел, что никаких use, require или import быть не должно, иначе нарушение будет

но вообще да - вроде как поинт человека был в том что DIP это только про направление зависимостей

а уже вот эти штуки это там DI и ioC и их часто путают

"кто создает" это один из вариантов IoC с реализацией оного в виде DI

при этом для реализации DIP тебе по сути не обязательно нужен DI

ну то есть здесь тоже dip?

зависимость же все равно есть и она не нужна, т.е. не dip должно быть

т.е. у нас затык со словом "зависимость" - вот с этим разобраться, наверное, надо
в примере с FileLogger в конструкторе, где-нить в php мне пришлось бы в композере прописывать пакет, где лежит этот FileLogger - зависимость же?
а вот код внутри класс, который работает с этим FileLogger уже не зависит от самого FileLogger, потому как работает через интерфейс
т.е. для кода нет зависимости (если не считать конструктора)
и где правда?

а, ну и dip же не говорит "класс", он, вроде, говорит "модули"
т.е. для класса с натяжкой еще можно считать, что зависимости нет, а вот для пакета она уже есть - ее не поставишь и остальное работать не будет
т.е. dip это все-таки про Service(LoggerInerface logger) и пофигу, что на di стало походить - оно о разном же

вообще если хочешь разобраться что такое DIP - представь что ты работаешь с Си

условно цель DIP - сделать так что бы обновление компонента поставляемого в виде динамически подключаемой библиотеки не требовали перекомпиляции всего проекта. Это то о чем дядя Боб твердит потому что он Сишник

я 17 лет с си не работал, это будет сложно )))
но вот именно это я и представляю, когда говорю про dip
а автор поста не согласен, у меня вопросы и возникли

то есть у DIP вполне практический профит. а не мифический который сложно осознать

потому как ее мысль тоже имеет право на существование
но если мое видение dip верное - у ее видения тоже название должно быть

ну я здесь про это и писал

в этом случае у тебя зависимость твоего модуля и на logger interface и на file logger так что ты сразу dip ломаешь. причем поскольку нет возможности подставить другую реализацию толку от интерфейса нет

во... про "толку нет" я и не подумал
тогда только один вопрос остался

Я еще почитал статью. Автор утверждает как раз то, что ты доказываешь. Вот ее вывод:

🔸Dependency invertion — класс работает с другими компонентами через интерфейс

Но у нее странный пример, который не сходится с ее выводом

interface Logger {…}
class FileLogger implements Logger {…}

class Service {
  Logger logger=new FileLogger();
}

Как-будто бы автор не относит конструктор к классу