Некоторое время назад мне нужно было пройти обучение архитектору. Что касается этого тренинга, я очень мало согласился с тем, что утверждал тренер, но было несколько вещей, которые он указал на то, что мы действительно знали о концепциях, о которых я уже знал и практиковал… но его описание было кратким и точным. Это была «инкапсуляция волатильности». Я собираюсь потратить некоторое время, чтобы поговорить об этом сегодня.

В больших программных системах или вообще в любом очень сложном инженерном подвиге… вы обычно разбиваете все на части. В большом сложном авиалайнере у вас есть любое количество избыточных подсистем, которые несут абсолютно критические обязанности. Так как же эти системы строятся и обслуживаются, и при этом хорошо работают друг с другом, надеюсь, с качеством и надежностью, которые люди ожидают найти на авиалайнере, ответственном за безопасную перевозку 300+ пассажиров из одного места в другое? Это точно такие же типы сценариев и решений, которые мы можем использовать сегодня, чтобы сделать код надежным и сделать его способным развиваться.

Представьте на мгновение информационно-развлекательную систему в вашем автомобиле или, возможно, в машине друзей (если в вашем автомобиле нет информационно-развлекательной системы). В некоторых реализациях есть крючки, которые достигают каждой подсистемы вашего автомобиля. Вы можете управлять интеграцией музыки/Bluetooth со своего телефона, контролировать окружающую среду, режимы производительности, следить за состоянием автомобиля и следить за расходом топлива. А теперь представьте, если бы эта автомобильная информационно-развлекательная система вышла из строя через 5 лет. Прямые замены могут быть недоступными или дешевыми. Поскольку у этой информационно-развлекательной системы есть щупальца в каждом маленьком элементе работы вашего автомобиля, найти стандартную замену на вторичном рынке будет чрезвычайно сложно.

Если бы усики выглядели так (как большинство программ и кода), замена этого компонента была бы кошмаром как для конечных пользователей, так и для производителей оборудования.

Теперь реальность, вероятно, такова, что по крайней мере НЕКОТОРЫЕ информационно-развлекательные системы абстрагируются от этих усиков, принимают некоторые стандарты, взаимодействующие через шину CAN (это не означает, что реализации этого или систем послепродажного обслуживания будут реализовывать каждый аспект этого… потому что шина CAN является несколько общей). стандарт)

В этой модели связь между информационно-развлекательной системой и другими системами существует в виде единого стандарта. (Случается, что это открытый стандарт, поэтому он не идеален 1: 1 по стандартам программного обеспечения и кодирования). В будущем, когда мы захотим обновить оборудование или полностью заменить его, нам нужно только гарантировать, что мы реализуем правильную реализацию интерфейса (спецификации шины CAN), и мы должны иметь возможность просто добавить новые компоненты.

Итак, как это связано с кодом. Куски кода, которые могут быть изменены в будущем. Любая конкретная технология или, возможно, поставщики систем хранения, когда мы говорим о развивающихся платформах, должны только определить «интерфейс», а сменные модули/компоненты должны только реализовать этот интерфейс.

Все это кажется очень логичным и очень похоже на то, что вы всегда слышали, когда речь шла о построении логического кода… сделайте его модульным, модульный совместим с эволюцией.

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

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

Всем хорошего дня и не забывайте узнавать что-то новое!