О критериях
Ограничимся минимумом объяснений, поэтому при первом чтении нельзя надеяться на понимание деталей всех перечисленных критериев; объяснение их - задача остальных разделов книги. Можно считать это обсуждение предваряющим просмотром - не настоящим кино, а анонсом. В отличие от анонса, эта лекция скорее является так называемым спойлером (spoiler) - она пересказывает сюжет, нарушая порой общий план книги. Этим она отличается от других лекций, в особенности лекций 3-6, терпеливо выстраивающих объектную технологию, рассматривающих проблему за проблемой на пути к получению и обоснованию решения. Если вам нравится идея обзора, предшествующая глубокому изучению вопросов, эта лекция для вас. Но если вы предпочитаете не портить удовольствия, открывая решения одно за другим, то просто пропустите ее.
Рассмотрим выбор критериев, позволяющих оценить объектную ориентированность системы (objectness).
До какой степени мы должны быть догматичными?
Список, представленный ниже, включает все свойства, кажущиеся существенными для создания высококачественного ПО ОО-методом. Наш список может показаться бескомпромиссным и даже догматичным. Какие заключения следует делать, если среда удовлетворяет некоторым, но не всем этим критериям? Следует ли считать ее полностью неадекватной?
Только вы, мой читатель, можете ответить на этот вопрос применительно к собственному контексту. Вот несколько причин, по которым может быть необходим компромисс:
[x]. Быть ОО-системой - это не булево условие. Из двух сред А и В первая может быть более объектно-ориентированной, хотя и не является таковой на все 100%. Поэтому если внешние ограничения сводят ваш выбор только к А и В, следует выбрать А как наименьшее из двух зол.
[x]. Не каждому нужны всегда все свойства.
[x]. Объектная ориентация может быть просто одним из факторов, определяющих наше решение, поэтому придется соблюдать баланс между критериями, приведенными здесь, и другими соображениями.
Все это не меняет очевидного: для обоснованного выбора, даже если практические ограничения навязывают далеко не совершенные решения, необходимо видеть полную картину.
Категории
Набор критериев делится на три части:
[x]. Метод и язык (Method and Language) : эти два почти не различимые аспекта охватывают мыслительные процессы и нотацию, использующуюся для анализа, проектирования и программирования ПО. Заметьте, что (особенно в объектной технологии) термин "язык" относится не только к языку программирования в строгом смысле, но также и к языкам анализа и проектирования и используемой в них нотации, текстовой или графической.
[x]. Реализация (Implementation) и Среда (Environment) : критерии в этой категории описывают основные свойства инструментария, позволяющего разработчикам применять ОО-идеи.
[x]. Библиотеки (Libraries) : объектная технология основана на повторном использовании компонентов ПО. Критерии в этой категории описывают как наличие базовых библиотек, так и механизмы, необходимые для их использования и создания новых библиотек.
Такое деление удобно, но не абсолютно, поскольку некоторые критерии относятся к двум или трем категориям. Например критерий, помеченный "управление памятью", относится к категории языка, поскольку язык может поддерживать или не допускать автоматическую сборку мусора. Этот же критерий относится к категории реализации и среды.
Метод и язык
Первый набор критериев относится к методу и поддерживающей его нотации.
Бесшовность (seamlessness)
ОО-подход амбициозен: он включает весь жизненный цикл ПО. При рассмотрении ОО-решений следует проверить, что метод, язык и поддерживающие их инструменты применимы к анализу и проектированию, а также к реализации и сопровождению. Язык, в частности, должен служить средством мышления, помогающим на всех стадиях работы.
В результате получается бесшовный процесс разработки, где общность концепций и нотации помогает сгладить переходы между последовательными ступенями жизненного цикла.
Эти требования исключают два часто встречающихся случая - оба неудовлетворительных:
[x]. Использование ОО-концепций на этапе анализа и проектирования с такой нотацией, которая не может использоваться на этапе программирования.
[x]. Использование ОО-языка программирования, неподходящего для этапа анализа и проектирования.
ОО-язык и ОО-среда, вместе с поддерживающим их методом, должны быть применимы ко всему жизненному циклу, минимизируя сложность переходов между последовательными шагами.
Классы
ОО-метод основан на понятии класса. Неформально, класс - элемент ПО, описывающий абстрактный тип данных и его частичную или полную реализацию. Абстрактный тип данных - множество объектов, определяемое списком компонентов (features) - операций, применимых к этим объектам, и их свойств.
Понятие класса должно быть центральной концепцией метода и языка.
Утверждения (Assertions)
Компоненты абстрактного типа данных имеют формально специфицированные свойства, отражаемые в соответствующих классах.
Утверждения - предусловия и постусловия программ класса и инварианты классов - играют эту роль.
Утверждения имеют три основных применения: помогают создать надежное ПО, обеспечивают систематическую документацию и являются инструментом тестирования и отладки ПО.
Язык должен давать возможность: поставлять класс и его компоненты вместе с утверждениями (предусловиями, постусловиями и инвариантами); включать инструментарий для получения документации из этих утверждений; осуществлять мониторинг утверждений во время выполнения программы.
В сообществе программных модулей, где классы являются городами, а инструкции - исполнительной ветвью власти, утверждения представляют законодательную власть. Ниже мы увидим, что играет роль судебной системы в таком сообществе.
Классы как модули
Объектная ориентация - в первую очередь архитектурная техника: она в основном затрагивает модульную структуру системы.
Здесь опять велика роль классов. Класс описывает не только тип объектов, но и модульную единицу. В чистом ОО-подходе:
Классы должны быть единственным видом модулей.
В частности, исчезает понятие главной программы, а подпрограммы не существуют как независимые модульные единицы (они могут появляться только как часть классов). Нет необходимости в "пакетах", используемых в таких языках, как Ada. Хотя удобно в целях управления группировать классы в административные единицы, называемые кластерами.
Классы как типы
Понятие класса достаточно мощное, чтобы избежать необходимости любого другого механизма типизации:
Каждый тип должен быть основан на классе.
Даже базовые типы, такие как INTEGER и REAL, можно рассматривать как классы; обычно такие классы являются встроенными.
Вычисления, основанные на компонентах
В ОО-вычислениях существует только один базовый вычислительный механизм. Есть некоторый объект, всегда являющийся (в силу предыдущего правила) экземпляром некоторого класса, и вычисление состоит в том, что данный объект вызывает некоторый компонент этого класса. Например, для показа окна на экране вызывается компонент display объекта, представляющего окно, - экземпляра класса WINDOW. Компоненты могут иметь аргументы: для увеличения зарплаты работника e на дату d, на n долларов, вызывается компонент raise объекта e, с аргументами n и d.