Что тогда нового в ОО-разработке? Ответ связан не с теоретическими возможностями метода (за исключением важных отличий, связанных со сборкой мусора, ОО-структуры времени выполнения идентичны своим аналогам в Pascal и Ada), а в практике разработки ПО. ОО-разработка подразумевает повторное использование. В частности, любой проект, в котором многочисленные прикладные классы выполняют хитрые манипуляции со ссылками, является примером некорректного использования ОО-подхода. Такие операции должны быть включены в библиотечные классы.
Для любой системы подавляющее большинство объектных структур, требующих нетривиальных операций со ссылками, не зависит от области приложения и представляет хорошо известные и часто используемые структуры: списки всевозможных типов, деревья в различных представлениях, хэш-таблицы и некоторые другие. В хорошей ОО-среде разработки библиотека должна быть легко доступной и предоставлять реализации подобных структур. В качестве иллюстрации в приложении A приведен эскиз библиотеки Base. Классы в таких библиотеках могут содержать множество ссылочных операций. Примером могут служить действия над ссылками, необходимые для вставки и удаления элемента связного списка или узла дерева.
Если же при разработке приложения появится потребность в сложных объектных структурах, не представленных адекватно в имеющихся библиотеках, то это следует рассматривать как потребность в новых классах общего назначения. Их необходимо разработать, потратить необходимое время на их тщательное тестирование и затем включить в соответствующую библиотеку. Такая ситуация в терминах одной из предшествующих лекций является примером перехода с позиций потребителя по отношению к повторному использованию на позиции производителя.
Оставшиеся операции со ссылками в классах, зависимых от конкретного приложения, должны быть ограничены простыми и безопасными операциями. В библиографических заметках упомянута статья Suzuki, развивающая эту идею.
В данной лекции введены некоторые правила и нотация для работы с объектами и соответствующими сущностями. Некоторые из этих соглашений могут вызвать удивление. Поэтому полезно завершить изучение объектов и их свойств рассмотрением спорных вопросов и доводов в пользу выбранных решений. Автор, естественно, надеется, что читатели полностью одобрят его выбор. Основная цель данной дискуссии - добиться полного понимания основополагающих проблем. В этом случае, если кто-то предпочитает другое решение, то сможет выбрать его вполне осознанно.
Для разминки начнем с небольшой проблемы, связанной с нотацией. Это конечно деталь, но из деталей складывается общая картина. Речь идет о наборе соглашений, используемых для графического представления классов и объектов.
В предшествующей лекции отмечалось насколько важно различать понятия класс и объект. Соответственно, должны отличаться и графические обозначения. Классы на диаграммах, представляющих системную архитектуру, представлены в виде эллипсов. Они соединяются стрелками для обозначения отношений между классами, обычными стрелками отмечаются отношения наследования и двойными - клиентские отношения.
Классы и объекты существуют в различных контекстах. Эллипсы классов являются частью диаграмм, представляющих структуру программной системы. Прямоугольники-объекты используются на моментальных снимках состояния системы в процессе выполнения. Поскольку указанные виды диаграмм имеют совершенно разное назначение, то в бумажном представлении, как в данной книге, они не появляются одновременно в одном контексте. Но для интерактивных CASE-средств ситуация принципиально меняется. В процессе отладки программной системы возникает необходимость отобразить объект, а затем - порождающий класс для изучения его компонент, родителей и других свойств.
Используемые для классов и объектов графические соглашения совместимы со стандартом, установленным методом BON (Nerson и Walden). В методе BON, (Business Object Notation) предназначенном для использования в интерактивных CASE-средствах и в документации, классы отображаются в виде пузырьков, растягиваемых по вертикали, показывающих компоненты класса, инварианты и другие свойства.(О BON см. библиографические заметки и лекцию 9 курса "Основы объектно-ориентированного проектирования")
В развитие нашего соглашения поля развернутых типов отличаются от ссылочных затенением, а подобъекты присутствуют в виде вложенных прямоугольников, содержащих собственные поля. Все эти соглашения вытекают из решения отображать объекты в виде прямоугольников.
Трудно удержаться от того, чтобы не процитировать следующий ненаучный аргумент, заимствованный из рецензии Ian Graham на книгу по ОО-анализу, использующую другие графические соглашения:
