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

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

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

Таким образом, как показывает пример с библиотекой публикаций, традиционные методы не обеспечивают решения проблемы, в то время как объектные технологии позволят получить ее решение благодаря двум методическим приемам, связанным с наследованием: полиморфизмом (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]. Принципы модульности применимы как к спецификации и проектированию, так и к реализации ПО.

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

[x]. Управление количеством и формой связей между модулями является основой разработки хорошей модульной архитектуры.

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

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

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

[x]. Открытым является такой модуль, который еще можно расширять.

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