Принцип инверсии зависимости: Как определить «политику высокого уровня» и «детализацию низкого уровня» для других людей?

Я пытаюсь объяснить принцип инверсии зависимостей моим (в основном младшим) коллегам. Как мы можем определить, какая из них является «политикой высокого уровня», а какая «низкоуровневой» в программном обеспечении? Например, если наше программное обеспечение автоматизирует рабочий процесс нескольких бизнес-приложений, почему мы говорим, что автоматизация рабочего процесса - это политика высокого уровня, а бизнес-приложения - это детали?

Примечание: это было полностью переписано из моего предыдущего примера

Подумайте о розетках. В любой стране политика высокого уровня заключается в том, что розетки всегда одинаковы. Неважно, откуда вы получаете электричество (уголь, газ, атомная энергия), розетки на стене всегда должны давать одинаковое количество энергии через один и тот же набор разъемов.

Теперь вы можете подключить любое устройство к этому разъему, потому что все они имеют общий интерфейс, «штекер». Политика высокого уровня никогда не должна диктовать какую-либо часть этой детали реализации. Просто подключите что-нибудь и все готово.

Теперь, если у вас есть устройство, которое не требует питания от сети переменного тока - возможно, оно работает на цепи 7 В постоянного тока - вы все равно можете использовать эту политику высокого уровня, вам просто нужен какой-то адаптер между источником питания и устройством. И поскольку у всех одинаковая политика высокого уровня, производитель может встроить ее в реализацию без каких-либо изменений политики высокого уровня. Человеку, связывающему реализацию с политикой (вы подключаете свой ноутбук), на самом деле тоже не нужно понимать.

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

Это прекрасный пример инверсии зависимостей.

Но вот интересный момент: вернитесь к тому, что я впервые сказал. «Неважно, откуда вы получаете электричество». Это также деталь реализации. Политика высокого уровня по-прежнему заключается в том, что все розетки питания имеют одинаковую форму и излучают одинаковый тип питания. Низкоуровневые детали реализации - это то, откуда и откуда идет электричество.

В терминах программирования это означает, что высокоуровневая политика - это интерфейс (где язык поддерживает его. Другой формой DI является типизация утки.), Который предоставляет API, и приложение потребляет, и детали реализации низкоуровневого уровня являются приложение потребляет его и сам API, ни один из которых не должен понимать друг друга.

Адаптеры могут использоваться для встраивания одной и той же реализации в разные политики.

Классический подход в повторном использовании программного обеспечения заключается в создании компонентов, которые не зависят ни от чего (именно это делает их низкоуровневыми), а затем создают компоненты более высокого уровня, которые зависят от компонентов более низкого уровня. «Высокий уровень» и «низкий уровень» определяются, в частности, направлением зависимости, которое не присуще функции компонента, а часто является просто архитектурным решением.

Итак, когда отдельные бизнес-приложения создаются без какой-либо зависимости от автоматизации рабочих процессов, но ваш контроллер рабочего потока имеет прямые зависимости от бизнес-приложения, тогда должно быть ясно, что автоматизация рабочих процессов является «политикой высокого уровня», а бизнес-приложение - компонент низкого уровня. Обратите внимание, что эта структура не обязательна - если ваш компонент автоматизации рабочих процессов является общей структурой, которая также не связана с вашими конкретными бизнес-приложениями, но может быть настроена для обслуживания различных приложений, то вы уже начали применять DIP. В этой ситуации разделение «высокий уровень» / «низкий уровень» может больше не иметь смысла между этими двумя вещами.

Таким образом, название «инверсия зависимостей» несколько вводит в заблуждение - поскольку зависимости не «инвертированы», а полностью удалены (или, если быть более точным: изменено с зависимости времени компиляции на зависимость во время выполнения).

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

Вместо того, чтобы верхние уровни располагались на нижних уровнях, более высокие уровни в мобильном интерфейсе взаимодействуют с нижними уровнями через строку, которая их соединяет. В некотором смысле, нижние уровни зависят от этого интерфейса для поддержки (без строки они упали бы). Это DIP в двух словах.