Генераторы текста не должны быть слишком сложными

 

Весь этот разговор об активном «этом» и пассивном «том», может создать у вас впечатление, что генераторы текста – сложные звери. Им не надо быть сложными. Обычно самой сложной частью является синтаксический анализатор, который обрабатывает входной файл. Не усложняйте входной формат, и генератор текста станет простым. Обратите внимание на ответ к упражнению 13 (см. Приложение В): в реальности генерация текста представляет собой в основном операторы print.

 

Рис. 3.4. Генерирование теиста из представления, независимого от языка. Строки во входном файле, начинающиеся с буквы М, означают начало определения сообщения, буква F означает строки с определениями полей, а буква Е – конец сообщения.

 

Генераторы текста не всегда генерируют тексты программ

 

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

 

Другие разделы, относящиеся к данной теме:

 

• Пороки дублирования

• Преимущество простого текста

• Злые волшебники

• Вездесущая автоматизация

 

Упражнения

 

13. Напишите генератор текста, который обрабатывает входной файл, изображенный на рисунке 3.4, и генерирует выходной файл на двух языках по вашему выбору. Попытайтесь упростить добавление новых языков. (Ответ см. в Приложении В.)

 

Глава 4

Прагматическая паранойя

 

Подсказка 30: Невозможно написать совершенную программу

 

 

Ваши чувства задеты? Не стоит принимать эту подсказку близко к сердцу. Примите ее как жизненную аксиому. Заключите ее в объятья. Восславьте ее. Поскольку совершенных программ в природе не существует. За всю краткую историю информатики никому не удалось написать ни одного совершенного фрагмента программы. Маловероятно, что вы станете первым. И когда вы примете это как существующий факт, то перестанете тратить время и энергию впустую в погоне за призрачной мечтой.

Каким же образом, учитывая эту гнетущую реальность, может прагматик обратить ее себе на пользу? Это и является темой данной главы.

Каждый знает, что лично он – лучший водитель на планете Земля. Остальному человечеству далеко до него, проезжающего под запрещающие знаки, мотающегося из ряда в ряд, не подающего сигналы поворота, разговаривающего по телефону, читающего за рулем газету и просто не живущего по общепринятым нормам. Так что мы ездим осторожно. Мы обнаруживаем неприятность до того, как она происходит, ожидаем непредвиденное и никогда не оказываемся в положении, из которого не сможем выпутаться сами.

Аналогия с написанием программ весьма очевидна. Мы постоянно взаимодействуем с программами, написанными другими людьми, программами, которые не отвечают нашим высоким требованиям, и имеем дело с входными параметрами, которые являются или не являются допустимыми. Нас учат программировать с осторожностью. При наличии любого рода сомнений мы проверяем правильность всей поступающей к нам информации. Мы используем утверждения для обнаружения неверных данных. Мы проверяем непротиворечивость, устанавливаем ограничения на столбцы базы данных и вообще высоко ценим самих себя.

Но прагматики идут дальше. Они не доверяют даже самим себе. Зная, что никто не пишет совершенных программ, включая их самих, прагматики пишут программы, защищаясь от собственных ошибок. Первый рубеж обороны описан в разделе "Проектирование по контракту": клиенты и поставщики должны договориться о правах и обязанностях.

В разделе "Мертвые программы не лгут" говорится о гарантиях того, что процедура устранения ошибок не нанесет вреда. Поэтому мы попытаемся чаще проверять нашу программу и завершать ее аварийно, если она работает не так, как надо.

В разделе "Программирование с применением утверждений" описан простой метод проверки "на ходу" – программа, которая активно проверяет ваши предположения.

Исключения, как и любая другая методика, может причинить больше вреда, чем пользы, если ее применять неправильно. Мы обсудим эти аспекты в разделе "Случаи, когда необходимо использовать исключения".

По мере того как ваши программы приобретают большую динамику, вы начинаете жонглировать системными ресурсами – памятью, файлами, устройствами и т. п. В разделе "Балансировка ресурсов" предлагаются способы того, как не ронять те предметы, которыми вы жонглируете.

Поэтому будем осторожными в этом мире несовершенных систем, устаревших временных масштабов, смешных инструментальных средств и невыполнимых требований.

 

Если все общество отклоняется от нормы, чтобы понять вас, скорее всего это паранойя.

Вуди Аллен

 

Проектирование по контракту

 

Ничто не ошеломляет людей так сильно, как здравый смысл и честная сделка.

Ральф Уолдо Эмерсон, Эссе

 

Работать с компьютерными системами всегда непросто. Работать с людьми еще сложнее. И поскольку мы (как биологический вид) развиваемся достаточно долго, то у нас явно было больше времени на выяснение природы человеческих взаимоотношений. Некоторые из тех решений, к которым мы пришли в течение нескольких последних тысячелетий, могут быть применены и к созданию программного обеспечения. Одним из лучших способов, с помощью которого можно удостовериться в честности заключаемой сделки, является контракт.

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

Допустим, у вас есть контракт на работу, где определены количество отрабатываемых часов и правила поведения, которым вы обязаны следовать. В ответ фирма платит вам заработную плату и предоставляет другие льготы. Каждая из сторон выполняет свои обязательства, а в результате выигрывают все.

Эта идея используется во всем мире – и формальным, и неформальным образом – для того, чтобы помочь людям во взаимодействии. Можем ли мы применить этот же принцип, чтобы способствовать взаимодействию программных модулей? Ответ на этот вопрос положительный.

 

Проектирование по контракту

 

Бертран Мейер [Меу97b] разработал концепцию проектирования по контракту для языка Eiffel [25]. Это простая, но мощная методика, сосредоточенная на документировании (и согласовании) прав и обязанностей программных модулей в целях обеспечения корректности программы. Так что же означает "корректная программа"? Это та программа, которая делает не более и не менее того, на что она претендует. Документирование и подтверждение указанных претензий лежит в основе принципа проектирования по контракту (в дальнейшем, для краткости, будем называть его ППК).

Каждая функция и метод в программной системе осуществляет некоторое действие. До того как подпрограмма начнет выполнять это действие, она может иметь некие виды на состояние окружающего мира, а также может констатировать состояние окружающего мира на момент завершения работы. Б. Мейер описывает эти виды и претензии следующим образом:

• Предусловия. Требования подпрограммы – то, что обязано быть истинным для того, чтобы подпрограмма могла вызываться. Если предусловия нарушены, программа не должна вызываться ни в коем случае. Ответственность за передачу качественных данных лежит на вызывающей программе (см. врезку ниже "Кто несет ответственность?").

• Постусловия. Состояние окружающего мира на момент завершения работы подпрограммы – то, что гарантируется подпрограммой. Сам факт того, что в ней имеется постусловие, подразумевает, что подпрограмма завершит свою работу: бесконечные циклы не допускаются.

• Инварианты класса. Класс гарантирует, что данное условие всегда истинно с точки зрения вызывающей программы. Во время внутренней обработки подпрограммы инвариант может и не выполняться, но к моменту выхода из подпрограммы и передачи управления обратно к вызывающей программе инвариант обязан быть истинным. (Следует заметить, что класс не может давать неограниченное право доступа для записи к любому элементу данных, участвующему в инварианте.)

Рассмотрим контракт на создание программы, которая осуществляет вставку значения данных в упорядоченный список уникальных данных. При работе с iContract (препроцессором для языка Java, который можно загрузить с [URL 17]) этот контракт может быть реализован следующим образом:

/**г

* ©invariant forall Node n in elements() |

* n.prev()!= null

* implies

* n.value().compareTo(n.prev().value()) > 0

*/

public class DBC_list {

/**

* @pre contains(aNode) == false

* @post contains(aNode) == true

*/

public void insertNode(final Node aNode) {

//…

Здесь стоит сказать, что элементы в списке всегда должны располагаться в порядке возрастания. При вставке нового элемента этот порядок уже может быть нарушен, и мы гарантируем, что элемент будет обнаружен после того, как он был вставлен в список.

Вы формулируете эти предусловия, постусловия и инварианты на целевом языке программирования, возможно, с некоторыми расширениями. Например, iContract предоставляет операторы логики предикатов – forall, exists и implies, дополняя обычные конструкции языка Java. Ваши утверждения могут сделать запрос о состоянии любого объекта, к которому имеется доступ со стороны метода, но удостоверьтесь, что запрос не окажет никакого побочного воздействия (см. ниже врезку "Утверждения и побочные условия").

 

ППК и параметры-константы

 

Во многих случаях постусловие будет использовать параметры, переданные в метод, для проверки правильности поведения. Но если подпрограмме разрешено изменять переданный параметр, то у вас есть возможность обойти условия контракта. В отличие от языка Java, язык Eiffel не позволяет подобных действий. В данном случае для указания наших намерений, сводящихся к неизменяемости параметра в пределах метода, используется ключевое слово final (из языка Java). Это не является "защитой от дурака" – подклассы не имеют ограничений при повторном определении параметра как не являющегося окончательным. В качестве альтернативы можно использовать синтаксис variable@pre (принятый в iContract), чтобы получить исходное значение переменной, существовавшее на момент входа в метод.

Следовательно, в контракте между подпрограммой и любой потенциально вызывающей ее программой может быть записано следующее:

 

"Если вызывающая программа выполняет все предусловия подпрограммы, то подпрограмма гарантирует, что по завершении ее работы все постусловия и инварианты будут истинными".

 

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

 

 

Подсказка 31: Проектируйте в соответствии с контрактами

 

 

В разделе «Ортогональность» рекомендуется создавать «скромные» программы. В данном случае упор делается на «ленивую» программу: проявите строгость в том, что вы принимаете до начала работы, и обещайте как можно меньше взамен. Следует помнить, что если в контракте указано, что вы принимаете все условия, а взамен обещаете весь мир, то вам придется написать… ну очень большую программу!

Наследование и полиморфизм являются краеугольными камнями объектно-ориентированных языков программирования и представляют собой область, в которой принцип программирования по контракту может проявиться особенно ярко. Предположим, что вы используете наследование при создании связи типа «это-схоже-с-тем», где один класс «схож-с-тем» (другим) классом. Вероятно, вы действуете в соответствии с принципом замещения, изложенным в книге "Liskov Substitution Principle" [Lis88]:

 

"Использование подклассов должно осуществляться через интерфейс базового класса, но при этом пользователь не обязан знать, в чем состоит различие между ними".

 

Другими словами, вы хотите убедиться в том, что вновь созданный подтип действительно "схож-с тем" (базовым) типом – что он поддерживает те же самые методы и эти методы имеют тот же смысл. Этого можно добиться при помощи контрактов. Контракт необходимо определить единожды (в базовом классе) с тем, чтобы он применялся к вновь создаваемым подклассам автоматически. Подкласс может (необязательно) использовать более широкий диапазон входных значений или же предоставлять более жесткие гарантии. Но, по крайней мере, подкласс должен использовать тот же интервал и предоставлять те же гарантии, что и родительский класс.

Рассмотрим базовый класс Java, именуемый java.awt.Component. Вы можете обрабатывать любой визуальный элемент в AWT или Swing как тип Component и не знать, чем является подкласс в действительности – кнопкой, подложкой, меню или чем-то другим. Каждый отдельный элемент может предоставлять дополнительные, специфические функциональные возможности, но, по крайней мере, он должен предоставлять базовые средства, определенные типом Component. Однако ничто не может помешать вам создать для типа Component подтип, который предоставляет методы с правильными названиями, приводящие к неправильным результатам. Вы легко можете создать метод paint, который ничего не закрашивает, или же метод setFont, который не устанавливает шрифт. AWT не обладает контрактами, которые способны обнаружить факт нарушения вами соглашения.

При отсутствии контракта все, на что способен компилятор, – это дать гарантию того, что подкласс соответствует определенной сигнатуре метода. Но если мы составим контракт для базового класса, то можем гарантировать, что любой будущий подкласс не сможет изменять значения наших методов. Например, вы составляете контракт для метода setFont (подобный приведенному ниже), гарантирующий, что вы получите именно тот шрифт, который установили:

 

/**

* @pre f!= null

* @post getFont() == f

*/

public void setFont(final Font f) {

//…

 

Реализация принципа ППК

 

Самая большая польза от использования принципа ПИК состоит в том, что он ставит вопросы требований и гарантий во главу угла. В период работы над проектом простое перечисление факторов – каков диапазон входных значений, каковы граничные условия, что можно ожидать от работы подпрограммы (или, что важнее, чего от нее ожидать нельзя), – является громадным шагом вперед в написании лучших программ. Не обозначив эти позиции, вы скатываетесь к программированию в расчете на совпадение (см. раздел "Программирование в расчете на стечение обстоятельств"), на чем многие проекты начинаются, заканчиваются и терпят крах.

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

 

Утверждения

 

Документирование этих предположений уже само по себе неплохо, но вы можете извлечь из этого еще большую пользу, если заставите компилятор проверять имеющийся контракт. Отчасти вы можете эмулировать эту проверку на некоторых языках программирования, применяя так называемые утверждения (см. "Программирование утверждений"). Но почему лишь отчасти? Разве вы не можете использовать утверждения для всего того, на что способен принцип ППК?

К сожалению, ответ на этот вопрос отрицательный. Для начала, не существует средств, поддерживающих распространение действия утверждений вниз по иерархии наследования. Это означает, что если вы отменяете метод базового класса, у которого имеется свой контракт, то утверждения, реализующие этот контракт, не будут вызываться корректно (если только вы не продублируете их вручную во вновь написанной программе). Не забывайте, что прежде чем выйти из любого метода необходимо вручную вызвать инвариант класса (и все инварианты базового класса). Основная проблема состоит в том, что контракт не соблюдается автоматически.

Кроме того, отсутствует встроенный механизм «старых» значений; т. е. значений, которые существовали на момент входа в метод. При использовании утверждений, обеспечивающих соблюдение условий контрактов, к предусловию необходимо добавить программу, позволяющую сохранить любую информацию, которую вы намерены использовать в постусловии. Сравним это с iContract, где постусловие может просто ссылаться на "variabie@pre", или с языком Eiffel, который поддерживает принцип "old expression".

И наконец, исполняющая система и библиотеки не предназначены для поддержки контрактов, так что эти вызовы не проверяются. Это является серьезным недостатком, поскольку большинство проблем обнаруживается именно на стыке между вашей программой и библиотеками, которые она использует (более детально этот вопрос обсуждается в разделе "Мертвые программы не лгут").