Чтение онлайн

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

[x]. Системы имеют децентрализованную архитектуру. Порядок действий несущественен для разработки.

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

[x]. Процесс компоновки может быть автоматизирован без использования Make-файлов и директив Include.

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

[x]. Экспорт атрибута означает доступ к нему только для чтения. Модификация требует вызова соответствующей экспортированной процедуры.

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

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

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

Понятие класса пришло из языка Simula 67 (см. библиографические ссылки к лекции 17 курса "Основы объектно-ориентированного проектирования"). Класс в Simula является одновременно модулем и типом, однако эта особенность специально не подчеркивалась и была утрачена у преемников Simula.

Принцип единственности цели может рассматриваться как аналог приема, хорошо известного в математической логике и теоретической компьютерной науке: редукция (currying). Редукция функции двух переменных f означает замену ее функцией g одной переменной, возвращающей в качестве результата функцию одной переменной. В результате редукции для любых допустимых значений x и y:

Редуцировать функцию это, другими словами, специализировать ее по первому аргументу. Этот прием аналогичен использованной в данной лекции замене традиционной процедуры rotate, имеющей два параметра:

на функцию с одним параметром, имеющую цель:

В [M 1990] описана редукция и некоторые из ее применений в информатике, в частности, при формальном изучении синтаксиса и семантики языков программирования. Редукция будет еще рассматриваться при обсуждении графического интерфейса пользователя (лекция 14 курса "Основы объектно-ориентированного проектирования").

В отличие от положений данной лекции в некоторых языках объект рассматривается как языковая конструкция, а не как понятие времени выполнения. Такой подход предназначен для исследовательских целей и не нуждается в понятии класса. Наиболее известным представителем этой школы является язык Self [Chambers 1991], в котором вместо классов используются "прототипы".

Детали соглашения об инфиксных и префиксных операциях, в частности таблица приоритетов, приведены в [M 1992].

James McKim обратил мое внимание на последний аргумент в пользу соглашения Result (использование для постусловий).

Напишите спецификацию абстрактного типа данных для описания точки на плоскости.

Завершите исходный текст класса POINT. Заполните недостающие фрагменты, добавьте процедуру rotate (вращение точки вокруг начала координат), а также другие компоненты, которые считаете необходимыми.

Перепишите класс POINT таким образом, чтобы в качестве базового использовалось бы представление точки в полярных, а не декартовых координатах.

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

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

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

В процессе выполнения ОО-система создает некоторое число объектов. Организация этих объектов и отношения между ними определяют конструкцию времени выполнения. Рассмотрим свойства объектов.

Прежде всего, необходимо напомнить смысл термина "объект". Полная ясность была внесена в предыдущей лекции в виде строгого определения (Определение и объективное правило, см. лекцию 7):

Определение: объект