Бертран Мейер - Основы объектно-ориентированного программирования

Одной из центральных тем при обсуждении повторного использования была необходимость соединить эту цель с адаптивностью во избежание дилеммы: переиспользоватьили переделывать. Этому в точности соответствует только что описанная схема, для которой можно предложить название "программы с дырами". В отличие от библиотек подпрограмм, в которых все, кроме значений фактических параметров, жестко фиксировано, у программ с дырами, использующих классы, образцом для которых служит модель SEQUENTIAL_TABLE , имеется место для частей, создаваемых пользователем.

Эти наблюдения помогают понять образ "блока Лего", часто используемый при обсуждении повторно использования. В наборе Лего компоненты фиксированы, детская фантазия направлена на составление из них интересной структуры. Тот же подход свойственен и программированию, - истоки его в традиционных библиотеках подпрограмм. Часто при разработке ПО требуется в точности обратное: сохранять структуру, но заменять компоненты. На самом деле, этих компонентов может еще и не быть, на их места помещаются "заглушки" (отложенные компоненты), вместо которых затем нужно вставить эффективные варианты.

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

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

Обычно даваемая в этом случае рекомендация состоит в использовании отдельных обозначений: некоторого "метода" анализа (за этим термином во многих случаях стоит просто некоторая графическая нотация) и некоторого ЯПП (PDL) (языка проектирования программ, зачастую тоже графического). Но у этого подхода много недостатков:

[x].Разрыв между последовательными шагами процесса разработки представляет серьезную угрозу для качества ПО. Необходимость трансляции из одного формализма в другой может привести к ошибкам и подвергает опасности целостность системы. ОО-технология, напротив, предлагает перспективу непрерывного процесса разработки ПО.

[x].Многоярусный подход является особенно губительным для этапов сопровождения и эволюции системы. Крайне сложно гарантировать согласованность проекта и реализации на этих этапах.

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

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

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

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

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

Роль предложения redefineсостоит в улучшении читаемости и надежности. Компиляторам, на самом деле, оно не нужно, так как в классе может быть лишь один компонент с данным именем, то объявленный в данном классе компонент, имеющий то же имя, что и компонент некоторого предка, может быть только переопределением этого компонента (или ошибкой).

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

Напомним правило использования конструкции Precursor (...) : она может появляться только в переопределяемой версии процедуры.

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