Шрифт:
Языки управления данными создают некую форму структуры данных, используемой приложением. Эти языки часто используются для представления конфигурации.
Например, программа sendmail применяется во всем мире для маршрутизации электронной почты в сети Интернет. Она обладает многими достоинствами и преимуществами, которые управляются огромным файлом конфигурации, написанном на собственном языке конфигурирования программы sendmail:
Mlocal, P=/usr/bin/procmail,
F=lsDFMAw5:/|@qSPfhn9,
S=10/30, R=20/40,
T=DNS/RFC822/X-Unix,
A=procmail -Y -a $h -d $u
Очевидно, удобочитаемость не является сильной стороной sendmail.
Уже давно фирма Microsoft использует язык данных, который может описывать меню, реквизиты окон, диалоговые окна и другие ресурсы Windows. На рис. 2.2 показан фрагмент типичного файла ресурсов. Он читается намного легче, чем пример с программой sendmail, но используется точно так же – компилируется для генерации структуры данных.
Рис. 2.2. Файл .rc для Windows
MAIN_MENU MENU
{
POPUP " &File"
{
MENUITEM "&New", CM_FILENEW
MENUITEM "&Open…", CM_FILEOPEN
MENUITEM "&Save", CM_FILESAVE
}
}
MY_DIALOG_BOX DIALOG 6,15,292,287
STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "My Dialog Box"
FONT 8, "MS Sans Serif"
{
DEFPUSHBUTTON «OK», ID_OK, 232,16, 50,14
PUSHBUTTON «Help», ID.HELP, 232, 52, 50,14
CONTROL "Edit Text Control", ID EDIT1, "EDIT", WS_BODER | WS_TABSTOP, 16,16, 80, 56
CHECKBOX «Checkbox», ID CHECKBOX 1,153, 65,42,38, BS_AUTOCHECKBOX | WS_ABSTOP
}
Процедурные языки идут дальше. В этом случае язык является исполняемым и поэтому может содержать инструкции, конструкции управления и т. п. (подобные сценарию на с. 50).
Вы также можете использовать собственные процедурные языки, чтобы облегчить сопровождение программы. Например, вас просят интегрировать информацию из унаследованного приложения в новую разработку графического интерфейса. Обычно это осуществляется при помощи "экранного кармана"; ваше приложение связывается с основным (mainframe) приложением так, как если бы это обычный пользователь-человек, генерируя нажатия клавиш и «считывая» принимаемые отклики. Вы можете создать сценарий взаимодействия при помощи мини-языка [14] .
14
На самом деле можно приобретать инструментальные средства, поддерживающие только этот способ написания сценариев. Кроме того, можно изучить пакеты с простым исходным текстом (типа Expect), в которых имеются подобные возможности [URL 24]) делается без компиляции. Это существенно упрощает сопровождение в области динамической области приложения.
locate prompt "SSN:"
type "%s" social_security_number
type enter
waitfor keyboardunlock
if text_at(10,14) is "INVALID SSN" return bad_ssn
if text_at(10,14) is "DUPLICATE SSN" return dup_ssn
# etc…
Когда приложение определяет, что пора вводить номер SSN, то по этому сценарию оно вызывает интерпретатор, который затем управляет транзакцией. Если интерпретатор встроен в приложение, то они даже могут совместно использовать данные (например, при помощи механизма обратного вызова).
В этом случае вы программируете в предметной области программиста сопровождения. Когда изменяется основное приложение и поля смещаются, программист может просто обновить высокоуровневое описание, вместо того чтобы копаться в подробностях программы на языке С.
Чтобы приносить пользу, мини-язык не должен использоваться приложением напрямую. Можно многократно использовать язык спецификации для создания искусственных объектов (включая метаданные), которые компилируются, считываются или используются самой программой иным образом (см. "Метапрограммирование").
Например, в разделе "Обработка текста" описывается система, в которой мы использовали Perl, чтобы генерировать большое количество выводов из первоначальной спецификации схемы. Мы изобрели общий язык, чтобы представить схему базы данных, и затем сгенерировали все его формы, которые нам необходимы, – SQL, С, интернет-страницы, XML и др. Приложение не использовало спецификацию напрямую, но оно полагалось на выходные данные, полученные из нее.
Обычной практикой является встраивание процедурных языков высокого уровня непосредственно в ваше приложение, так, чтобы они исполнялись, когда исполняется ваша программа. Очевидно, что это мощное средство; можно изменять поведение приложения, варьируя сценарии, которые оно считывает, причем все это
Мы рассмотрели несколько различных грамматик – от простых строчно-ориентированных форматов до более сложных, которые выглядят как реальные языки. Если для реализации требуются дополнительные усилия, тогда зачем выбирать более сложную грамматику?
Компромиссом являются расширяемость и сопровождение. В то время как программа грамматического разбора «реального» языка может быть более сложной в написании, для пользователя она будет намного понятнее, и ее будет легче расширить за счет добавления новых средств и функциональных возможностей. Слишком простые языки могут быть легкими для грамматического разбора, но они могут быть зашифрованными – подобно примеру с программой sendmail (см. "Языки управления данными и процедурные языки").
Учитывая, что срок службы большинства прикладных программ превышает ожидаемый, вам лучше примириться с суровой действительностью и принять заранее более сложный и удобочитаемый язык. Усилия, затраченные вначале, многократно окупятся за счет снижения затрат на поддержку и сопровождение.
• Метапрограммирование
• Можно ли выразить некоторые из требований проекта, над которым вы работаете в настоящее время, на языке, отражающем специфику предметной области? Возможно ли написать компилятор или транслятор, который мог бы сгенерировать большую часть требуемой программы?