Суть архитектурного паттерна заключается в том, что поведение системы в значительной мере определяется данными, подаваемыми на вход программы. Ключевое в этой фразе - "в значительной мере". Давайте рассмотрим на примере: пусть у нас есть программа, которая засасывает данные с ftp и пересылает их куда-либо, ну допустим в папку на сетевом диске. Простой не-data-driven подход заключается в том чтобы скормить созданному экзешнику конфиг с информацией о параметрах подключения к ftp и пути к папке на сетевом диске. В этом случае поведение системы незначительно варьируется содержимом конфига. Мы можем забирать данные с одного ftp или с другого, выкладывать в ту или иную папку. Но схема работы всегда будет одна и та же - ftp->папка. Более сложный data-driven подход заключается в том, что созданному экзешнику будут передаваться настройки того как забирать файлы и как их складывать. Исходя из поставленной задачи у нас может быть два способа ftp/папка, но в силу организации кода, мы можем получить следующие варианты передачи файлов ftp->папка, ftp->ftp, папка->ftp, папка->папка. Эти четыре варианта и есть то поведение, которое в значительной степени определяется настройками. На практике, такая архитектура автоматически приводит к тому, что клиентский код становится более простым и понятным, появляются фабрки, создающие необходимые нам объекты по переданным конфигам. И в пределе получается интерпретатор скриптов-конфигов, который сам по себе ничего не делает, но в зависимости от настроек может выполнять достаточно широкий спектр задач.
Вот буквально вчерашний пример - необходимо создать механизм валидации полей формы. Вариант первый - захардкодить все проверки в клиентском коде. Говно метод прямо скажем. Второй, значительно лучший вариант, заключается в том, что бы создать простенький язык для описания того, какими свойствами должны обладать значения, введенные в поля формы и научить программу работать с выражениями этого языка. На практике это стало означать следующее:
// проверяем $_POST[ 'login' ], $_POST[ 'password' ], $_POST[ 'password_confirm' ], validate( 'login:filled,max_len_20,min_len_6#password:filled,equal_to_password_confirm#password_confirm:filled' );
Вот так, одной строчкой проверили всю форму регистрации. Data-driven подход делает этот код понятным с одного беглого взгляда. Если реализовать ту же проверку "в лоб", то это будет как минимум 6 if-ов, разбирательство в которых будет требовать времени. Не о говоря уже о том что это будет с десяток строчек кода.
Последний пример на эту тему - на одной из моих предыдущих работ встала задача зарефакторить систему автоматического обновления моей программы. Проблема была в том, что каждое обновление было реализовано в виде dll-шки что вызывало ряд неудобств. Я решил воспользоваться data-driven подходом. В итоге обновление стало представлять из себя xml со списком необходимых действий. Т.е. простейший скрипт. В результате этого рефакторинга, количество кода сократилось почти в 100 раз!
Буду до конца честным: этот подход годится не для всех случаев, так, например, для небольших программ это будет только лишний геморрой и стрельбой из пушки по воробьям. Хотя для больших проектов данный подход поможет сделать код более лаконичным и понятным.
ЗЫ Та самая статья, о которой шла речь в начале заметки: Юрий Блажевич, Игровой движок управляемый данными. ogg, ppt
ЗЫЫ Ссылки по теме:
Качество кода
Исключения
Организация кода
Open source убьёт мир
Фокусы с наследованием
Стандарты кодирования
Старые парадигмы о главном