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

[x].Не каждому нужны всегда все свойства.

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

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

Набор критериев делится на три части:

[x]. Метод и язык (Method and Language): эти два почти не различимые аспекта охватывают мыслительные процессы и нотацию, использующуюся для анализа, проектирования и программирования ПО. Заметьте, что (особенно в объектной технологии) термин "язык" относится не только к языку программирования в строгом смысле, но также и к языкам анализа и проектирования и используемой в них нотации, текстовой или графической.

[x]. Реализация (Implementation) и Среда (Environment): критерии в этой категории описывают основные свойства инструментария, позволяющего разработчикам применять ОО-идеи.

[x]. Библиотеки (Libraries): объектная технология основана на повторном использовании компонентов ПО. Критерии в этой категории описывают как наличие базовых библиотек, так и механизмы, необходимые для их использования и создания новых библиотек.

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

Первый набор критериев относится к методу и поддерживающей его нотации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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