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

тщательное тестирование и затем включить в соответствующую библиотеку. Такая ситуация в терминах одной из предшествующих лекций является примером перехода с позиций потребителя по отношению к повторному использованию на позиции производителя.

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

Обсуждение

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

Графические соглашения

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

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

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

Используемые для классов и объектов графические соглашения совместимы со стандартом, установленным методом BON (Nerson и Walden). В методе BON, (Business Object Notation) предназначенном для использования в интерактивных CASE-средствах и в документации, классы отображаются в виде пузырьков, растягиваемых по вертикали, показывающих компоненты класса, инварианты и другие свойства.(О BON см. библиографические заметки и лекцию 9 курса 'Основы объектно- ориентированного проектирования')

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

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

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

Ссылки и простые значения

Важный синтаксический вопрос - должны ли мы установить синтаксическое различие при работе со ссылками и простыми значениями. Как отмечалось, присваивание и эквивалентность имеют различный смысл для ссылок и значений развернутых типов. Но синтаксис этого не различает, - в обоих случаях используются одинаковые символы (:=, =, /=). Не опасно ли это? Не предпочтительнее ли использовать различные наборы символов, напоминая тем самым, что они имеют разный смысл?

Два набора символов использовались в языке Simula 67. Немного изменив нотацию для совместимости с настоящей книгой (в языке Simula reference сокращается до ref), в Simula можно записать объявление сущности ссылочного типа Cтак:

x: reference C

Ключевое слово reference указывает, что экземпляры x будут ссылками. Рассмотрим объявления:

m, n: INTEGER
x, y: reference C

Нотация Simula, используемая для операций с простыми и ссылочными типами, приведена в таблице.

Операция	Операнды развернутых типов	Операнды-ссылки
Присваивание	m := n	x :- y
Проверка на равенство	m = n	x == y
Проверка на неравенство	m /= n