8.8. ПРОЕКТНАЯ ПРОЦЕДУРА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ ПО Б. СТРАУСТРУПУ
8.8. ПРОЕКТНАЯ ПРОЦЕДУРА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ ПО Б. СТРАУСТРУПУ
8.8.1. Укрупненное изложение проектной процедуры Б. Страуструпа
Б. Страуструп — автор объектно-ориентированного языка программирования C++ с множественным наследованием. У Б. Страуструпа при описании методики проектирования вводится единица проектирования — "компонента". Под компонентой понимается множество классов, объединенных некоторым логическим условием, иногда это общий стиль программирования или описания, иногда — предоставляемый сервис. Ряд авторов вместо термина "компонента" используют термин "модуль".
Структура компонент проектируется использованием итерационного нарастающего процесса. Обычно для получения проекта, который можно уверенно использовать для первичной реализации
или повторной, нужно несколько раз проделать последовательность из следующих четырех шагов.
Шаг 1. Выделение понятий (классов, порождающих объекты) и установление основных связей между ними.
Шаг 2. Уточнение классов с определением наборов операций (методов) для каждого.
Шаг 3. Уточнение классов с точным определением их зависимостей от других классов. Выясняется наследование и использование зависимостей.
Шаг 4. Задание интерфейсов классов. Более точно определяются отношения классов. Методы разделяются на общие и защищенные. Определяются типы операций над классами.
8.8.2. Шаг 1. Выделение понятий и установление основных связей между ними
Выделение объектов производится во время процесса мысленного представления системы. Часто это происходит как цикл вопросов "что/кто". Команда программистов определяет: что требуется делать? Это немедленно приводит к вопросу: кто будет выполнять действие? Теперь программная система в значительной мере становится похожей на некую организацию. Действия, которые должны быть выполнены, присваиваются некоторому программному объекту в качестве его обязанностей.
Понятия (объекты) соответствуют порождающим классам и могут иметь форму в виде имен существительных и, как экзотика, глаголов и имен прилагательных.
Часто говорят, что понятия в форме имен существительных играют роль классов и объектов, используемых в программе. Например: трактор, редуктор, гайка, редактор, кнопка, файл, матрица. Это действительно так, но это только начало.
Глаголы могут представлять операции над объектами или обычные (глобальные) функции, вырабатывающие новые значения, исходя из своих параметров, или даже классы. В качестве примера можно рассматривать манипуляторы, предложенные А. Кенигом. Суть идеи манипулятора в том, что создается объект, который можно передавать куда угодно и который используется как функция. Такие глаголы, как "повторить" или "совершить", могут быть представлены итеративным объектом или объектом, представляющим операцию выполнения программы в базах данных.
Даже имена прилагательные можно успешно представлять с помощью классов. Например, такими классами могут быть: "хранимый", "параллельный", "регистровый", "ограниченный", — а также классы, которые помогут разработчику или программисту, задав виртуальные базовые классы, специфицировать и выбрать нужные свойства для классов, проектируемых позднее.
Все классы можно условно разделить на две группы: классы из предметной (прикладной) области и классы, являющиеся артефактами реализации или абстракциями периода реализации.
Классы из предметной (прикладной) области — непосредственно отражают понятия из прикладной области, т. е. понятия, которые использует конечный пользователь для описаний своих задач и методов их решения.
Лучшее средство для поиска этих понятий/классов — грифельная доска, а лучший метод первого уточнения — беседа со специалистами в области приложения или просто с друзьями. Обсуждение необходимо, чтобы создать начальный словарь терминов и понятийную структуру.
Главное в хорошем проекте — прямо отразить какое-либо понятие "реальности", т. е. уловить понятие из области приложения классов, представить взаимосвязь между классами строго определенным способом, например с помощью наследования, и повторить эти действия на разных уровнях абстракции.
Классы, являющиеся артефактами реализации или абстракциями периода реализации, — это те понятия, которые применяют программисты и проектировщики для описания методов реализации:
• классы, отражающие ресурсы оборудования (оперативная память, механизмы управления ресурсами, дисковое пространство);
• классы, представляющие системные ресурсы (процессы, потоки ввода-вывода);
• классы, реализующие программные структуры (стеки, очереди, списки, деревья, словари и т. п.);
• другие абстракции, например элементы управления программой (кнопки, меню и т. п.).
Хорошо спроектированная система должна содержать классы, которые дают возможность рассматривать систему с логически разных точек зрения.
Пример:
1) классы, представляющие пользовательские понятия (например, легковые машины и грузовики);
2) классы, представляющие обобщения пользовательских понятий (движущиеся средства);
3) классы, представляющие аппаратные ресурсы (например, класс управления памятью);
4) классы, представляющие системные ресурсы (например, выходные потоки);
5) классы, используемые для реализации других классов (например, списки, очереди);
6) встроенные типы данных и структуры управления.
В больших системах очень трудно сохранять логическое разделение типов различных классов и поддерживать такое разделение между различными уровнями абстракции. В приведенном выше перечислении представлены три уровня абстракции:
(1+2) — представляет пользовательское отражение системы;
(3+4) — представляет машину, на которой будет работать система;
(5+6) — представляет низкоуровневое (со стороны языка программирования) отражение реализации.
Чем больше система, тем большее число уровней абстракции необходимо для ее описания и тем труднее определять и поддерживать эти уровни абстракции. Отметим, что таким уровням абстракции есть прямое соответствие в природе и в различных построениях человеческого интеллекта. Например, можно рассматривать дом как объект, состоящий из атомов; молекул; досок и кирпичей; стен, пола и потолков; комнат.
Пока удается хранить раздельно представления этих уровней абстракции, можно поддерживать целостное представление о доме. Однако если смешать их, возникнет бессмыслица.
Взаимоотношения, о которых мы говорим, естественно устанавливаются в области приложения или (в случае повторных проходов по шагам проектирования) возникают из последующей работы над структурой классов. Они отражают наше понимание основ области приложения и часто являются классификацией основных понятий. Пример такого отношения — машина с выдвижной лестницей есть грузовик, есть пожарная машина, есть движущееся средство.
8.8.3. Шаг 2. Уточнение классов с определением набора операций (методов) для каждого
В действительности нельзя разделить процессы определения классов и выяснения того, какие операции для них нужны. Однако на практике они различаются, поскольку при определении классов внимание концентрируется на основных понятиях, не останавливаясь на программистских вопросах их реализации, тогда как при определении операций прежде всего сосредоточиваются на том, чтобы задать полный и удобный набор операций. Часто бывает слишком трудно совместить оба подхода, в особенности, учитывая, что связанные классы надо проектировать одновременно.
Возможно несколько подходов к процессу определения набора операций. Предлагаем следующую стратегию:
— рассмотрите, каким образом объект класса будет создаваться, копироваться (если нужно) и уничтожаться;
— определите минимальный набор операций, необходимый для понятия, представленного классом;
— рассмотрите операции, которые могут быть добавлены для удобства записи, и включите только несколько действительно важных;
— рассмотрите, какие операции можно считать тривиальными, т. е. такими, для которых класс выступает в роли интерфейса для реализации производного класса;
— рассмотрите, какой общности именования и функциональности можно достигнуть для всех классов компонента.
Очевидно, что это стратегия минимализма. Гораздо проще добавить любую функцию, приносящую ощутимую пользу, и сделать все операции виртуальными. Но чем больше функций, тем больше вероятность, что они не будут использоваться, наложат определенные ограничения на реализацию и затруднят эволюцию системы. Гораздо легче включить в интерфейс еще одну функцию, как только установлена потребность в ней, чем удалить ее оттуда, когда уже она стала привычной.
Причина, по которой мы требуем явного принятия решения о виртуальности данной функции, не оставляя его на стадию реализации, в том, что, объявив функцию виртуальной, существенно повлияем на использование ее класса и на взаимоотношения этого класса с другими.
При определении набора операций (методов) больше внимания следует уделять тому, что надо сделать, а не тому, как это сделать.
Иногда полезно классифицировать операции класса по тому, как они работают с внутренним состоянием объектов:
1) базовые операции: конструкторы, деструкторы, операции копирования;
2) селекторы: операции, не изменяющие состояния объекта;
3) модификаторы: операции, изменяющие состояние объекта;
4) операции преобразований, т. е. операции, порождающие объект другого типа, исходя из значения (состояния) объекта, к которому они применяются;
5) повторители: операции, которые открывают доступ к объектам класса или используют последовательность объектов.
Кроме уже перечисленных групп методов, в классы могут быть введены дополнительные методы самотестирования и проверки корректности данных. Это не есть разбиение на ортогональные группы операций. Например, повторитель может быть спроектирован как селектор или модификатор.
Выделение этих групп просто предназначено помочь в процессе проектирования интерфейса класса. Конечно, допустима и другая классификация.
8.8.4. Шаг 3. Уточнение классов с точным определением их зависимостей от других классов
Виды взаимоотношений между классами могут быть следующими: отношения наследования; отношения включения; отношения использования; запрограммированные отношения.
Еще одно взаимоотношение — отношение включения {агрегирования) — класс содержит в виде члена объект или указатель на объект другого класса. Позволяя объектам содержать указатели на другие объекты, можно создавать так называемые "иерархии объектов". Такие реализации альтернативно дополняют возможности использования иерархии классов.
Очень важным при проектировании является вопрос: какое отношение выбрать — агрегации (включения) или наследования. В принципе эти методы взаимозаменяемы, кроме случая, когда используется позднее связывание. Наиболее предпочтителен тот вариант, в котором наиболее точно моделируется окружающая действительность, т. е. если понятие X является частью понятия Y, то используется включение. Если понятие X более общее, чем Y, — то наследование.
Для составления и понимания проекта часто необходимо знать, какие классы и каким способом они используются, другими словами, отношения использования. Возможно следующим образом классифицировать те способы, с помощью которых класс X может использовать класс Y.
— X использует Y;
— X вызывает функцию-член (метод) Y;
— X читает член Y;
— X пишет в член Y;
— X создает Y;
— X размещает переменную из Y
Анализ подобных взаимосвязей позволяет выявить потребности в определенных методах классов или, наоборот, выявить их ненужность.
Запрограммированные отношения — те отношения проекта, которые не могут быть прямо представлены в виде конструкций языка. Допустим, в проекте оговорено, что каждая операция, не реализованная в классе А, должна обслуживаться объектом класса В. К запрограммированным отношениям относят также операции преобразования типов. Следует, по возможности, избегать применения этого вида отношений из-за усложнения реализации. Идеальный класс должен в минимальной степени зависеть от остального мира. Следовательно, следует стараться минимизировать зависимости.
8.8.5. Шаг 4. Задание интерфейсов классов
Спрячем подробности реализации за фасадом интерфейса. Объект инкапсулирует поведение, если он умеет выполнять некоторые действия, но подробности, как это делается, остаются скрытыми за фасадом интерфейса. Эта идея была сформулирована специалистом по информатике Дэвидом Парнасом в виде правил, которые часто называются принципами Парнаса.
Правило 1. Разработчик программы должен предоставлять пользователю всю информацию, которая нужна для эффективного использования приложения, и ничего кроме этого.
Правило 2. Разработчик программного обеспечения должен знать только требуемое поведение объекта и ничего кроме этого.
Следствие принципа отделения интерфейса от реализации состоит в том, что программист может экспериментировать с различными алгоритмами, не затрагивая остальные классы объектов программы.
На этом шаге дается четкое описание классов, их данных и методов (опуская реализацию и, возможно, скрытые методы). Всем методам задаются точные типы параметров.
Идеальный интерфейс представляет пользователю полный и последовательный набор понятий; согласован со всеми частями компоненты; не открывает подробности реализации и может быть реализован различными способами; ограниченно и четко определенным образом зависит от других интерфейсов.
Интерфейсы классов предоставляют полную информацию для реализации классов на этапе кодирования.
Существует золотое правило: если класс не допускает, по крайней мере, двух существенно отличающихся реализаций, то что-то явно не в порядке с этим классом, это просто замаскированная реализация, а не представление абстрактного понятия. Во многих случаях для ответа на вопрос: "Достаточно ли интерфейс класса независим от реализации?" — надо указать, возможна ли для класса схема обычных вычислений.
8.8.6. Перестройка иерархии классов
Пытаясь провести классификацию некоторых новых объектов, задаем следующие вопросы: В чем сходство этого объекта с другими объектами общего класса? В чем его различия? Каждый класс имеет набор поведений и характеристик, которые его определяют. Начнем с верхушки фамильного дерева образца и будем спускаться по ветвям, задавая эти вопросы на протяжении всего пути. Более высокие уровни являются более общими, а вопросы — более простыми. Каждый уровень является более специфическим, чем предыдущий уровень, и менее общим.
Без сомнения, это тривиальная задача, но установить идеальную иерархию классов для определенного применения очень трудно. Прежде чем написать строку кода программы, необходимо хорошо подумать о том, какие классы необходимы и на каком уровне. По мере того как увеличивается понимание, может оказаться, что необходимы новые классы, которые фундаментально изменяют всю иерархию классов.
На втором и третьем шагах итеративной процедуры проектирования производится выявление того, насколько адекватно классы и их иерархия подходят по сути проекта. Проектировщики вынуждены реорганизовывать, улучшать проект и повторять все шаги сначала, и так до тех пор, пока качество проекта не будет удовлетворительным.
При перестройке иерархии классов применяются четыре процедуры: расщепление класса на два и более; абстрагирование (обобщение); слияние; анализ возможности использования существующих разработок.
Расщепление применяется в следующих случаях:
1) если имеется сложный класс, иногда имеет смысл разделить его на несколько простых классов и тем самым обеспечить поэтапную разработку;
2) класс содержит ряд несвязанных между собой функций или набор независимых друг от друга данных.
Обобщение — выявление в группе классов общих свойств и вынесение их в общий базовый класс. Признаки необходимости обобщения таковы:
1) общая схема использования;
2) сходство между наборами операций;
3) сходство реализаций;
4) эти классы часто фигурируют вместе в дискуссиях по проекту.
Слияние — объединение нескольких небольших, но тесно взаимодействующих классов в один. Таким образом, взаимодействие будет скрыто в реализации нового класса.
Использование существующих разработок. Обособленный класс или группа классов из уже существующего проекта может быть легко интегрирована в новый класс. Однако подобная интеграция вносит определенные ограничения в структуру системы и может сказаться на эффективности разработки самой программы. Изготовители систем объектно-ориентированного программирования поставляют системы с совместимыми библиотеками классов. Очевидно, чем больше готовых библиотечных классов будет использовано в программе, тем меньше кода придется писать при реализации программы.
8.8.7. Свод правил
В рассмотренных ранее темах не было дано настоятельных и конкретных рекомендаций по проектированию. Это соответствует убеждению, что нет "единственно верного решения". Принципы и приемы следует применять такие, которые лучше подходят для решения конкретных задач. Для этого нужен вкус, опыт и разум. Тем не менее можно указать некоторый свод правил (эвристических приемов), который разработчик может использовать в качестве ориентиров, пока не будет достаточно опытен, чтобы выработать лучшие правила. Ниже приведен свод таких эвристических правил.
Правило 1. Узнайте, что вам предстоит создать.
Правило 2. Ставьте определенные и осязаемые цели.
Правило 3. Не пытайтесь с помощью технических приемов решить социальные проблемы.
Правило 4. Рассчитывайте на большой срок в проектировании и управлении людьми.
Правило 5. Используйте существующие системы в качестве моделей, источника вдохновения и отправной точки.
Правило 6. Проектируйте в расчете на изменения: гибкость, расширяемость, переносимость, повторное использование.
Правило 7. Документируйте, предлагайте и поддерживайте повторно используемые компоненты.
Правило 8. Поощряйте и вознаграждайте повторное использование: проектов, библиотек, классов.
Правило 9. Сосредоточьтесь на проектировании компоненты.
Правило 10. Используйте классы для представления понятий.
Правило 11. Определяйте интерфейсы так, чтобы сделать открытым минимальный объем информации, требуемой для интерфейса.
Правило 12. Проводите строгую типизацию интерфейсов всегда, когда это возможно.
Правило 13. Используйте в интерфейсах типы из области приложения всегда, когда это возможно.
Правило 14. Многократно исследуйте и уточняйте как проект, так и реализацию.
Правило 15. Используйте лучшие доступные средства для проверки и анализа проекта и реализации.
Правило 16. Экспериментируйте, анализируйте и проводите тестирование на самом возможном раннем этапе.
Правило 17. Стремитесь к простоте, максимальной простоте, но не сверх того.
Правило 18. Не разрастайтесь, не добавляйте возможности "на всякий случай".
Правило 19. Не забывайте об эффективности.
Правило 20. Сохраняйте уровень формализации, соответствующий размеру проекта.
Правило 21. Не забывайте, что разработчики, программисты и даже менеджеры остаются людьми.
8.8.8. Пример простейшего проекта
Б. Страуструп придумал реализацию механизма множественного наследования и при этом отвергал агрегирование, хотя и реализовал это в своем языке C++.
Приведенный далее пример показывает невозможность осуществления решения следующей простой задачи двумя способами решения — с использованием множественного наследования и агрегирования. В процессе решения задач было выявлено, что в ряде задач без выполнения третьего шага невозможно корректное выполнение второго шага. Таким образом, при решении одного и того же примера двумя способами второй и третий шаги проекта были взаимно переставлены. Также добавлен шаг "классификация объектов" (составление словаря).
Первый способ решения задачи — использование множественного наследования.
Постановка задачи примера. Вывести на экран фигуру, показанную на рис. 8.4.
Рис. 8.4. Изображение выводимой фигуры
Изображенная на рис. 8.4 фигура состоит из правильного пятиугольника и описанной вокруг него окружности, где хс, yc — координаты центра описанной вокруг пятиугольника окружности; R — радиус описанной вокруг пятиугольника окружности.
Кроме того, фигура рисуется заданным цветом.
Следует отметить, что задача может быть решена несколькими способами.
Шаг 1а. Определение объектов и выявление их свойств.
Объект — Рисунок. Свойства объекта:
— радиус окружности (R);
— координаты центра окружности (xc; yc);
— цвет линий.
Объект — Пятиугольник. Свойства объекта:
— радиус описанной вокруг него окружности (R);
— координаты центра описанной вокруг него окружности (хс; yc):
— цвет линии.
Объект — Окружность. Свойства объекта:
— радиус (R);
— координаты центра (хс; yc);
— цвет линии.
Решение задачи примера с использованием множественного наследования.
Шаг 1б. Классификация объектов (составление словаря).
Пятиугольник — центрально-симметричная фигура с пятью вершинами.
Окружность — центрально-симметричная фигура, каждая точка которой отстоит от заданной точки — центра, на заданную величину — радиус окружности.
Полученный граф наследования классов изображен на рис. 8.5.
Шаг 2. Уточнение классов с точным определением их зависимостей от других классов. Выясняется наследование и использование зависимостей.
Рис. 8.5. Граф наследования классов согласно первому способу
Поскольку Пятиугольник и Окружность — это разновидности центрально-симметричных фигур, то им может соответствовать следующая иерархия классов. Базовый класс: Центрально-симметричная фигура с данными R, хс, yc. Классы Пятиугольник и Окружность являются наследниками этого класса, а класс Рисунок является наследником классов Окружность и Пятиугольник, поскольку в данной задаче рисунок является сочетанием пятиугольника и окружности.
Шаг 3. Уточнение классов с определением наборов операций для каждого. Здесь анализируется потребность в конструкторах, деструкторах и операциях копирования. При этом принимается во внимание минимальность, полнота и удобство.
Класс Рисунок. Экземпляр этого класса должен создаваться и рисоваться, а следовательно, в интерфейсе класса Рисунок должны присутствовать конструкторы и функция — член рисования рисунка. Тогда получаем:
• конструктор без параметров;
• конструктор с параметрами (Радиус, х-координата, y-координата, Цвет);
• функцию-член вывода рисунка — "Начертить".
Класс Пятиугольник. Экземпляр этого класса должен создаваться и рисоваться, а следовательно, в интерфейсе класса Пятиугольник должны присутствовать конструкторы и функция-член рисования пятиугольника. Тогда получаем:
• конструктор без параметров;
• конструктор с параметрами (Радиус, х-координата, y-координата);
• функцию-член вывода пятиугольника на экран — "Начертить".
Класс Окружность. Экземпляр этого класса должен создаваться и рисоваться, а следовательно, в интерфейсе класса Окружность должны присутствовать конструкторы и функция-член вывода окружности на экран. Тогда получаем:
• конструктор без параметров;
• конструктор с параметрами (Радиус, х-координата, у-координата);
• функцию-член вывода окружности на экран — "Начертить".
Класс Центрально-симметричная фигура. Экземпляр данного класса должен содержать информацию о центрально-симметричной фигуре в виде данных с защищенным доступом (не интерфейсная часть класса) и иметь чисто-виртуальную функцию перерисовки вместе с конструкторами. Тогда получаем:
• конструктор без параметров;
• конструктор с параметрами (Радиус, х-координата, y-координата);
• чисто-виртуальную функцию-член вывода изображения на экран.
Шаг 4. Задание интерфейсов классов. Более точно определяются отношения классов. Методы разделяются на общие и защищенные методы. Определяются типы операций над классами.
Данные, расположенные в классе Центрально-симметричная фигура (R, хс, yc), должны быть доступны классам-наследникам Пятиугольник и Окружность, но недоступны "извне", значит, уровень доступа — "защищенный". В классе Центрально-симметричная фигура нужно расположить функцию "Нарисовать", которую предполагается сделать чисто-виртуальной. Классы, наследующие у класса Центрально-симметричная фигура, смогут переопределить функцию "Нарисовать" для рисования самих себя.
Поскольку обоим объектам — экземплярам классов Пятиугольник и Окружность нужен только один центр на двоих, то, следовательно, экземпляр класса Центрально-симметричная фигура должен создаваться только один, а значит, при описании наследования в языке C++ нужно добавить зарезервированное слово virtual. Наследование классами Пятиугольник и Окружность признаков у класса Центрально-симметричная фигура должно происходить с открытым уровнем доступа, иначе при создании класса Рисунок мы не сможем запустить конструктор класса верхнего уровня. Наследование классом Рисунок признаков классов Пятиугольник и Окружность должно происходить закрыто, чтобы к методам этих классов нельзя было обратиться через объект класса Рисунок. К наследуемым признакам добавляется свойство "Цвет линии", значение которого будет храниться в классе Рисунок. В классе Рисунок, так же как и в классах Пятиугольник и Окружность, можно переопределить метод "Нарисовать". Этот метод выводит изображения на экран, в нем как раз и будет устанавливаться цвет линий, при котором будут рисоваться фигуры.
Второй способ решения задачи с использованием агрегирования. Поскольку шаги 1а и 1б выполняются полностью аналогично предшествующему способу решения, начинаем с шага 2.
Шаг 2. Уточнение классов с точным определением их зависимостей от других классов. Выясняется наследование и использование зависимостей.
Объект рисунок состоит из объектов пятиугольник и окружность, форма и размер которых определяются настройками, задаваемыми при создании объекта рисунок, т. е. можно создать два независимых класса Пятиугольник (правильный) и Окружность, а затем экземпляры этих классов агрегировать в объект рисунок — экземпляр класса Рисунок.
Шаг 3. Уточнение классов с определением наборов операций для каждого. Здесь анализируется потребность в конструкторах, деструкторах и операциях копирования. При этом принимается во внимание минимальность, полнота и удобство.
Класс Рисунок. Объект этого класса должен уметь создать, уничтожить и нарисовать себя, поэтому интерфейсная часть класса будет следующей:
• конструктор без параметров;
• конструктор с параметрами (Радиус, x-координата, y-координата, Цвет);
• метод вывода рисунка на экран;
• деструктор для уничтожения создаваемых включенных объектов.
Примечание. Включение объектов типов Пятиугольник и Окружность происходит в закрытой, не интерфейсной части класса.
Класс Пятиугольник. Объект класса Пятиугольник должен уметь создать и рисовать себя, поэтому интерфейсная часть класса будет выглядеть следующим образом:
• конструктор без параметров;
• конструктор с параметрами (Радиус, x-координата, y-координата);
• метод вывода пятиугольника на экран.
Класс Окружность. Объект класса Окружность должен создавать и рисовать сам себя, поэтому интерфейсная часть класса будет выглядеть следующим образом:
• конструктор без параметров;
• конструктор с параметрами (Радиус, x-координата, y-координата);
• метод вывода окружности на экран.
Шаг 4. Задание интерфейсов классов. Более точно определяются отношения классов. Методы разделяются на общие и защищенные. Определяются типы операций над классами.
Классы Окружность и Пятиугольник должны содержать внутри себя переменные R, xc, yc, которые должны быть закрыты для доступа; функцию-член вывода фигуры на экран для доступа — открытую (как и конструкторы).
Для класса Рисунок включаемые экземпляры классов Пятиугольник и Окружность являются полями, поэтому их нужно скрыть, чтобы командовать этими объектами мог только экземпляр класса Рисунок. Функцию вывода рисунка на экран, как и конструкторы, нужно сделать открытыми.
Анализ результатов шагов 2 и 3 показывает, что проектная процедура допускает предварительное выполнение определения набора операций до определения зависимостей класса от других классов с последующим уточнением наборов операций классов.