Антон Аксёнов 06.08.2024
Часто в разговорах между программистами можно услышать разговор об уровнях: высокоуровневые классы (модули, функции), низкоуровневые классы. Или, "это высокоуровневый слой/политика".
Вот тут надо понимать такое на уровне спинного мозга, что это за уровень (почему - чуть ниже)
Суть простая: чем ближе твой код к пикселу на мониторе, к транзистору на постоянно запоминающем устройстве (или контроллере головки дисковода), к контроллеру подачи чернил на принтере, к Цифро-Аналоговому Преобразователю сетевой карты (или звуковой), к Аналого-Цифровому Преобразователю клавиатуры или мыши- тем ниже уровень этого кода.
Ведь всё что мы программируем в итоге передаётся к этим вещам, вызов идёт от функции к функции - всё ниже и ниже у нас в коде, затем в дебрях браузера, затем браузер вызывает API операционной системы, там тоже пара прыжков и ныряем уже в драйвер конкретного устройства, там тоже внутри несколько вызовов внутренних функций и вот напряжение подаётся на исполняющее устройство, которое уже делает что-то полезное (или не очень) в физическом смысле. Ну и обратно, при замыкании проводков или изменении напряжения на оптическом датчике (и т.д.) идёт обратная цепочка вызовов и возвращаемся в наш высокоуровневый JavaScript в какой-нибудь onClick, имея за спиной цепочку вызовов длиной в полтора экрана :)
Проще говоря - чем ближе к железу - тем ниже уровень. А чем ближе к бизнес-логике - тем выше уровень. И эти два понятия, железо и БЛ должны быть всегда на разных сторонах линейки.
Итак, почему это важно. А всё просто: зависимости классов/компонентов/модулей друг от друга (т.е. один класс знает про/использует другой) нужно строить так что бы низкоуровневый код зависел от высокоуровневого, но не наоборот. Это прям аксиома. Высокоуровневый код, как капризная принцесса, выставляет наружу требования (в виде описанного интерфейса, типа interface IStorage {save(data)}), а какая-нибудь низкоуровневая система хранения этот интерфейс имплементирует - т.е. выполняет эти требования. И капризной принцессе всё равно как именно и кем выполняются её требования - главное что выполняются. Если так строить зависимости то основная ценность программы - бизнес-логика (принцесса) - будет отделена от деталей реализации (где хранит, как передаёт, куда отрисовывает), это за собой влечёт массу преимуществ, начиная от простоты тестирования заканчивая простотой поддержки при изменении этих самый деталей - БД там сменить или добавить вывод на принтер помимо монитора.
Это всё хорошо (гораздо лучше) описано в той самой книжке "Чистая архитектура" Роберта Мартина, если что. Я не рекламы ради (хотя почему нет), книга действительно хорошая, для меня в своё время стала откровением - я много из того что было в книжке делал "на ощупь" после наступания на массу граблей, а тут дядька взял и вывел правила и сделал книжку.
