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

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

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

Оставшиеся операции со ссылками в классах, зависимых от конкретного приложения, должны быть ограничены простыми и безопасными операциями. В библиографических заметках упомянута статья 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, используемая для операций с простыми и ссылочными типами, приведена в таблице.

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

Соглашения Simula лишены неоднозначности. Почему бы их не сохранить? К сожалению, эти соглашения могут служить примером благих намерений, приносящих скорее вред, нежели пользу. Проблемы начинаются в прозаической области поиска ошибок. Два набора символов похожи, - это провоцирует синтаксические ошибки, подобные использованию := вместо :- .

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