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

Эти требования исключают два часто встречающихся случая - оба неудовлетворительных:

[x]. Использование ОО-концепций на этапе анализа и проектирования с такой нотацией, которая не может использоваться на этапе программирования.

[x]. Использование ОО-языка программирования, неподходящего для этапа анализа и проектирования.

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

Классы

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

Понятие класса должно быть центральной концепцией метода и языка.

Утверждения (Assertions)

Компоненты абстрактного типа данных имеют формально специфицированные свойства, отражаемые в соответствующих классах.

Утверждения - предусловия и постусловия программ класса и инварианты классов - играют эту роль.

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

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

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

Классы как модули

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

Здесь опять велика роль классов. Класс описывает не только тип объектов, но и модульную единицу. В чистом ОО-подходе:

Классы должны быть единственным видом модулей.

В частности, исчезает понятие главной программы, а подпрограммы не существуют как независимые модульные единицы (они могут появляться только как часть классов). Нет необходимости в "пакетах", используемых в таких языках, как Ada. Хотя удобно в целях управления группировать классы в административные единицы, называемые кластерами.

Классы как типы

Понятие класса достаточно мощное, чтобы избежать необходимости любого другого механизма типизации:

Каждый тип должен быть основан на классе.

Даже базовые типы, такие как INTEGER и REAL, можно рассматривать как классы; обычно такие классы являются встроенными.

Вычисления, основанные на компонентах

В ОО-вычислениях существует только один базовый вычислительный механизм. Есть некоторый объект, всегда являющийся (в силу предыдущего правила) экземпляром некоторого класса, и вычисление состоит в том, что данный объект вызывает некоторый компонент этого класса. Например, для показа окна на экране вызывается компонент display объекта, представляющего окно, - экземпляра класса WINDOW. Компоненты могут иметь аргументы: для увеличения зарплаты работника e на дату d, на n долларов, вызывается компонент raise объекта e, с аргументами n и d.

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

Вызов компонента должен быть основным механизмом вычисления.

Класс, содержащий вызов компонента класса C, называют клиентом класса С .

Вызов компонента иногда называют передачей сообщения (message passing) ; по этой терминологии вышеприведенный вызов будет описываться как передача объекту e сообщения: "повысить вашу плату" с аргументами d и n.

Скрытие информации (information hiding)

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

Механизм, делающий определенные компоненты недоступными для клиентов, называется скрытием информации.

На практике бывает недостаточно того, чтобы механизм скрытия информации поддерживал экспортируемые компоненты (доступные для всех клиентов) и скрытые компоненты (не доступные ни одному клиенту).

Создатели классов должны также иметь возможность избирательно экспортировать компоненты для избранных клиентов.

Автор класса должен иметь возможность указать, что компонент доступен: всем клиентам, ни одному клиенту или избранным клиентам.

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

Обработка исключений (Exception handling)