Определение термина: Вынесение в декларацию
Вынесение в декларацию — проектное решение, при котором постоянные, редко изменяемые или конфигурируемые параметры, структуры, правила, сценарии и пр. переносятся из тела кода в отдельную декларацию (функцию, массив, JSON, YAML и т.д.). Основной код работает с этими декларациями как с “источником истины”.
Для справки по принципам: SOLID.
Как решить, что выносить в декларацию?
Чтобы использовать этот подход максимально эффективно, рекомендуется перед проектированием кода задать себе следующие вопросы:
-
Какие части логики часто меняются, а какие стабильны?
-
Всё, что меняется редко, можно вынести в декларацию (например, схемы данных, правила валидации, список действий, типы форматов, шаблоны, фиксированные сценарии).
-
-
Можно ли выразить параметры или правила в виде структурированных данных, а не кода?
-
Если да — лучше вынести их в массив, объект, JSON, YAML и использовать как декларацию.
-
-
Сможет ли команда (или сторонний пользователь) модифицировать требования без вмешательства в логику?
-
Если такой сценарий нужен — декларация позволит изменять поведение без изменений в кодовой базе.
-
-
Есть ли дублирующаяся логика, которую можно сделать универсальной и параметризуемой?
-
Вынесите различающиеся детали в декларацию, а обработку — сделайте общей.
-
-
Что важнее: гибкость или производительность?
-
В ряде случаев декларативность может внести небольшие накладные расходы, но окупается за счёт масштабируемости и простоты изменений.
-
Рекомендация
Начинайте проектирование с выявления “точек изменяемости” и статических (постоянных) частей системы. Всё, что может быть задано “данными” вместо кода — выносите в декларацию. Основной алгоритм пусть работает с этими декларациями.
Преимущества
-
Гибкость: Изменения — только в декларации, а не в коде.
-
Расширяемость: Новые сценарии/правила добавляются декларативно.
-
Переиспользуемость: Один и тот же код обслуживает разные схемы и сценарии.
-
Прозрачность: Вся бизнес‑логика или политика “на виду” и легко проверяется.
Пример 1: Валидация данных по схеме
Описание:
Описываем структуру и требования к данным декларативно, а универсальный валидатор работает с любыми схемами.
// Декларация
$schema = [
'username' => ['type' => 'string', 'required' => true, 'maxLength' => 30],
'email' => ['type' => 'string', 'required' => true, 'pattern' => '/@/'],
'age' => ['type' => 'int', 'min' => 18],
];
function validate(array $data, array $schema) {
foreach ($schema as $field => $rules) {
if (!array_key_exists($field, $data)) {
if (!empty($rules['required'])) {
throw new Exception("Field {$field} is required");
}
continue;
}
$value = $data[$field];
if ($rules['type'] === 'int' && !is_int($value)) {
throw new Exception("Field {$field} must be integer");
}
if ($rules['type'] === 'string' && !is_string($value)) {
throw new Exception("Field {$field} must be string");
}
if (isset($rules['maxLength']) && strlen($value) > $rules['maxLength']) {
throw new Exception("Field {$field} too long");
}
if (isset($rules['pattern']) && !preg_match($rules['pattern'], $value)) {
throw new Exception("Field {$field} invalid");
}
if (isset($rules['min']) && $value < $rules['min']) {
throw new Exception("Field {$field} too small");
}
}
}
Преимущество:
Если требуется новое поле или правило — добавьте в декларацию, валидатор изменять не нужно.
Пример 2: Генерация форм по декларации
Описание:
Структура формы и правила отображения описываются в массиве. Генерация HTML и обработка инпутов строится автоматически.
$formConfig = [
'fields' => [
'login' => [
'type' => 'text',
'label' => 'Логин',
'required' => true,
],
'password' => [
'type' => 'password',
'label' => 'Пароль',
'required' => true,
'minLength' => 8,
]
]
];
function renderForm(array $config) {
foreach ($config['fields'] as $name => $field) {
echo "<label>{$field['label']}<input type='{$field['type']}' name='{$name}'";
if (!empty($field['required'])) echo " required";
if (!empty($field['minLength'])) echo " minlength='{$field['minLength']}'";
echo "></label><br>";
}
}
Преимущество:
Изменение структуры формы и её ограничений делается только в декларации.
Пример 3: Маппинг действий или бизнес‑логики
Описание:
Вместо if‑else или switch‑case для маршрутизации действий используется декларация, связывающая действия с обработчиками.
$actions = [
'create_user' => 'App\\Actions\\CreateUserAction',
'send_email' => 'App\\Actions\\SendEmailAction',
'export_csv' => 'App\\Actions\\ExportCsvAction',
];
function handleAction($actionName, $params) {
global $actions;
if (!isset($actions[$actionName])) {
throw new Exception("Unknown action: $actionName");
}
$handlerClass = $actions[$actionName];
$handler = new $handlerClass();
return $handler‑>execute($params);
}
Преимущество:
Добавление нового действия требует только добавления его в массив и создания обработчика, основной алгоритм не изменяется.
Итог
Вынесение в декларацию — это универсальная техника, повышающая качество и гибкость кода.
Применяйте её везде, где можно отделить структуру или правила от самой логики, — это облегчит развитие, поддержку и сопровождение ваших решений.