Что-то не могу понять этот принцип. Информация, которую я читал, выглядит противоречивой.

Вот оригинал:

https://en.wikipedia.org/wiki/Dependency_inversion_principle High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).
Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

1. Какой определить у какого модуля/класса выше уровень?
2. Могут ли зависеть низкоуровые модули от высокоуровневых?

andreykaTзависимость должна быть в одну сторону. т.е. если на пальцах твой репозиторий не должен знать ничего о контроллере и сервисах. твой сервис ничего не должен знать о контроллере, твой контроллер в идеальном мире ничего не должен знать о тех обоих. вроде так мартин вещал. если речь об аббревиатуре солид.

Речь про SOLID

Это отвечаете на какой вопрос?

andreykaT1) где верх где низ - это зависит от твоей архитектуры и что ты там пишешь я хз. главное что вызовы из одного слоя должны ходить только в другой и никак не наоборот. если вдруг тебе понадобилось в другую сторону - ты делаешь что-то не так.
2) тут идея в том, что объясняя на пальцах, если у тебя какая-нибудь классика контроллер-сервис-репозиторий это подразумевается, что из репозиторя ты не должен обращаться к сервису, или контроллеру. только так: контроллер -> сервис -> репозиторий.

Это я и так всё знаю, но это не выглядит соответсвующе формулировке. Вчитайтесь


авторHigh-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).

Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.


1. Какой определить у какого модуля/класса выше уровень?
2. Могут ли зависеть низкоуровые модули от высокоуровневых?

контроллер выше сервиса?

andreykaT,

Да дело не в чтении, а в понимании.

В случае спринга точка входа запроса это контроллер.

То есть контроллер это верхняя точка, сервис на уровень ниже, репозиторий ещё ниже.


теперь берём фразу
авторHigh-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).

Почему она написана именно так?

Если как Вы говорите, то надо писать:
автор low-level modules should not depend High-level modules.

Kachalovquestionerберём фразу
пропущено...


Почему она написана именно так?
- вероятно потому, что здесь смысл заключен во втором предложении, про абстрации, что бы не писали:


а писали:




а в первую фразу для красоты написали?

andreykaTинверсия с английского вообще переводится как гомосексуализм

очень познавательно. А главное очень относится к теме.

andreykaTда. гомосексуальная зависимость. всё верно. блин. ну посмотри ж ты книжку того чела который собрал эти принципы а. там немного страниц и всё объяснено картинками тем челом кто эту диай и сформулировал как бестпрактиз

Судя по тому, что ты прочитал, а объяснить не можешь эта книжка тебе не помогла.

Нужели никто не может ответить?

andreykaTавторОбратите внимание, что поток управления пересекает извилистую линию в направлении, обратном направлению зависимостей в исходном коде. Зависимости следуют в направлении, противоположном направлению потока управления — именно поэтому принцип получил название принципа инверсии зависимости

Как это всё соотносится с фразой:

авторHigh-level modules should not depend on low-level modules.

maytonНовичку проще понять эту тему если представить что между модулями стоит сеть.

Новичком меня тяжело назвать)

andreykaT,

https://stackoverflow.com/a/3780447/2674303 In laymen's terms: high level modules depend on low level modules, but shouldn't depend on their implementation. This can be achieved by using interfaces, thus decoupling the definition of the service from the implementation.

Я пришёл к выводу, что под любым модулем автор понимает имплементацию и причина непонимания кроется то ли в терминологии, то ли в лингвистике и если по русски, то это будет звучать так, что Модули высокого уровня вместо того, чтобы зависеть от имплементации модулей нижнего уровня должны зависеть от их обобщённых интерфейсов. Таким образом написав другую имплементацию мы сможем её переиспользовать не меняя остальной код.

Конечно выглядит слегка притянутым за уши, но лучшего ничего не придумал.

andreykaTс другой стороны, там есть такая фраза:

авторИзвилистая линия делит систему на два компонента: абстрактный и конкретный. Абстрактный компонент содержит все высокоуровневые бизнесправила приложения. Конкретный компонент содержит детали реализации
этих правил.
Обратите внимание, что поток управления пересекает извилистую линию
в направлении, обратном направлению зависимостей в исходном коде.
возможно, тут разгадка что такое хайлевел модуль.



А там это где? в книге?

Ох как загнули с линией, остроумно))

Я не уверен, что до конца понял, что ключевую фразу авторОбратите внимание, что поток управления пересекает извилистую линию
в направлении, обратном направлению зависимостей в исходном коде.


типо по интерфейсу найдётся имплементация? то бишь полиморфизм == Dependency inversion?

PetroNotC Sharp,

Братюнь, ты предоставил только одну ссылку на которой нет стрелок.
Про буржуазный язык прости, но 90% информации на нём - рекомендуется как можно раньше понять, что не надо его чураться

Nixicquestioner1. Какой определить у какого модуля/класса выше уровень?
2. Могут ли зависеть низкоуровые модули от высокоуровневых?
1. Данные поступают в первый, потом во второй и т.д. классы/методы, кто раньше получил данные, тот и на верхнем уровне,
в частности контроллер(в который добавлен сервис), затем сервис(в котором репозиторий и всякие конвертеры и мапперы), затем репозиторий.
2. Нет, не могут. Нельзя в сервис или в репозиторий добавить контроллер, нельзя в репозиторий добавить сервис. И всё в таком духе.

И все они связаны через интерфейсы.
Вроде всё понятно. Наверное, надо реальный проект посмотреть, сразу вся логика становится очевидной и логичной.

Человек который прочитал только заголовок detected.

PetroNotC SharpquestionerБратюнь, ты предоставил только одну ссылку на которой нет стрелок.там ссылка второго уровня.
Там больше и читать нечего.

questionerне надо его чураться
Я не чураюсь. Я прочитал обе вики, а ты русскую не читал, и сейчас опять не прочитал все ссылки там на обсуждение.
И самое главное КОД С ПРИМЕРАМИ.

Вот этого перца? https://blog.byndyu.ru/2009/12/blog-post.html

этого читал причём ещё до публикации вопроса

PetroNotC Sharpquestionerэтого читал причём ещё до публикации вопросатогда в чем вопрос?
Тут такое дело.
Одни угадывают DI с двух нот. Другие с 3_х. А третьи всю жизнь используют, но с одной ноты не угадывают.
Может толкование такое. Или учителя попались такие.
Попробуй на французском толкования.
Я лично предпочмтаю примеры.
Примеры понятны? В коде?

Надо всё таки прочитать топик с начала) Вы ничего нового не открыли. В целом я думаю в какой-то степени мы докопались до истины.

забыл никquestioner,
а зачем тебе понимать чбе-бы-то-ни-было толкование? Вообще при чтении этой темы меня не покидают ощущение что я нахожусь в кружке толкователей корана

Ну вроде это написано не 100 лет назад. Поэтому выглядит, что "толковать" ничего не надо, а толкователей в статьях пруд пруди. А потому, что написано настолько "забористо", что с ходу не понятно, что хотел сказать автор. Я понимаю, что это обобщенные абстрактные принципы, но тем не менее, приятно понимать оригинал. Вдруг там что-то ещё есть)

Просто фраза "модули высокого уровня не должны зависеть от модулей нижнего уровня" для меня выглядит реально противоречивой. По факту же модули высокого уровня(контроллеры из всем известного spring mvc например) зависят от сервиса. Ну вытащу я этот сервис в интерфейс - ок - буду зависеть от интерфейса модуля нижнего уровня. Я бы всё равно это оценил таким образом, что модуль высокого уровня зависит от модуля нижнего уровня хоть и через его интерфейс.