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

Чтобы с помощью p осуществлять какие-либо полезные действия, необходимо явно выделить различные случаи:

case p of
book:... Instructions which may access the field p.publisher...
journal:... Instructions which may access fields p.volume, p.issue...
proceedings:... Instructions which may access fields p.editor, p.place...
end

Здесь оказалась удобной команда выбора case из языков Pascal и Ada; ее синтаксис воспроизводит определение типа записи с вариантами. В Fortran'е и C это может имитироваться многократным использованием команды безусловного перехода goto (switch в языке C). В этих и других языках такой же результат можно получить, используя вложенные команды условного перехода (if ... then ... elseif ... elseif ... else ... end).

Следует отметить, что, независимо от используемой синтаксической конструкции, для осуществления такого выбора каждый модуль-клиент должен знать полный список вариантов представления для публикации, поддерживаемых модулем A. Последствия этого нетрудно предвидеть. Наступит момент, когда потребуется новый вариант, например технические отчеты фирм и университетов. Тогда необходимо расширить определение типа PUBLICATION в модуле A, учитывающее новый случай. Это вполне логично и неизбежно: если было изменено определение понятия публикации, то следует обновить и соответствующее объявление типа. Однако значительно труднее найти оправдание другому следствию: любой клиент модуля A, такой как B, также будет требовать обновления, если в нем использовалась рассмотренная выше структура, основанная на полном списке случаев для p. А это, очевидно, будет иметь место для большинства клиентов.

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

Эта проблема возникнет всякий раз, когда некоторое понятие допускает множество вариантов. Здесь таким понятием было 'публикация' ('publication'), а его начальными вариантами были: книга (book), журнальная статья (journal article), труды конференции (conference proceedings); другими типичными примерами могут быть:

[x]. В системе работы с графикой: понятие фигуры (figure), с такими вариантами как многоугольник (polygon), окружность (circle), эллипс (ellipse), отрезок (segment) и другие основные виды фигур.

[x]. В текстовом редакторе: понятие команды пользователя (user command), с такими вариантами как вставка строки (line insertion), удаление строки (line deletion), удаление символа (character deletion), глобальная замена (global replacement) одного слова другим.

[x]. В компиляторе для языка программирования: понятие языковой конструкции (language construct), с такими вариантами как команда (instruction), выражение (expression), процедура (procedure).

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

Принцип Единственного Выбора

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

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

Таким образом, как показывает пример с библиотекой публикаций, традиционные методы не обеспечивают решения проблемы, в то время как объектные технологии позволят получить ее решение благодаря двум методическим приемам, связанным с наследованием: полиморфизмом (polymorphism) и динамическим связыванием (dynamic binding). Однако приведенного здесь предварительного обсуждения недостаточно; эти методические приемы можно будет понять лишь в контексте всего метода наследования. (См. 'Динамическое связывание' лекция 4)

Принцип Единственного Выбора нуждается еще в нескольких комментариях:

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

[x]. Подобно другим правилам и принципам, обсужденным в этой лекции, принцип Единственного Выбора касается распределения знаний (distribution of knowledge) в системе ПО. Этот вопрос является действительно решающим при поиске расширяемых, многократно используемых программных средств. Чтобы получить цельную, надежную архитектуру ПО, следует предпринять строго обдуманные шаги по ограничению объема информации, доступной каждому модулю. По аналогии с методами, используемыми некоторыми общественными организациями, можно назвать это принципом необходимого знания (need-to-know): запретить каждому модулю доступ к любой информации, которая не является безусловно необходимой для его надлежащего функционирования.

[x]. Можно рассматривать принцип Единственного Выбора как прямое следствие принципа Открыт-Закрыт. Обсудим пример с библиотекой публикаций в свете рисунка, иллюстрирующего необходимость в открытых и закрытых модулях: A это модуль, содержащий первоначальное описание типа PUBLICATION; клиенты B, C это модули, зависящие от исходного списка вариантов; A' это усовершенствованная версия A, предлагающая дополнительный вариант - технические отчеты (technical reports). (См. второй рисунок в разделе 'Открыт- Закрыт')

[x]. Можно также понимать этот принцип как сильную форму принципа Скрытия Информации. Разработчик модулей-поставщиков, таких как A и A', стремится скрыть информацию (относительно точного списка вариантов для некоторого понятия) от модулей-клиентов.

Ключевые концепции

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

[x]. Модули служат как для декомпозиции программного обеспечения (проектирование сверху вниз), так и для его композиции (снизу-вверх).

[x]. Принципы модульности применимы как к спецификации и проектированию, так и к реализации ПО.