Программирование. Принципы и практика использования C++ Исправленное издание

Страуструп Бьерн

14. Определите класс для прямоугольного треугольника. Составьте восьмиугольник из восьми прямоугольных треугольников разного цвета.

15. Покройте окно узорами в виде маленьких прямоугольных треугольников.

16. Покройте окно узорами в виде маленьких шестиугольников.

17. Покройте окно узорами в виде маленьких разноцветных шестиугольников.

18. Определите класс

Poly

, представляющий многоугольник, так, чтобы его конструктор проверял, действительно ли его точки образуют многоугольник. Подсказка: вы должны передавать в конструктор координаты точек.

19. Определите класс

Star

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

Послесловие

В

главе 12 мы играли роль пользователей классов. В этой главе мы перешли на один уровень вверх по “пищевой цепочке” программистов: здесь мы стали разработчиками классов и пользователями инструментов программирования.

Глава 14

Проектирование графических классов

“Польза, прочность, красота”.

Витрувий (Vitruvius)

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

14.1. Принципы проектирования

Каковы принципы проектирования наших классов графического интерфейса? Сначала надо разобраться в смысле поставленного вопроса. Что такое “принципы проектирования” и почему мы должны говорить о них, вместо того, чтобы заняться созданием изящных рисунков?

14.1.1. Типы

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

Цель проектирования — отразить понятия предметной области в тексте программы. Если вы хорошо разбираетесь в предметной области, то легко поймете код, и наоборот. Рассмотрим пример.

•

Window

— окно, открываемое операционной системой.

•

Line

— линия, которую вы видите на экране.

•

Point

— точка в системе координат.

•

Color

— цвет объекта на экране.

•

Shape

— общие свойства всех фигур в нашей модели графики или графического пользовательского интерфейса.

Последнее понятие,

Shape

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

Shape

будет пресечена компилятором.

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

Следовательно, мы должны сосредоточиться на простоте и гибкости библиотеки.

На самом деле ни одна библиотека не способна моделировать все аспекты предметной области. Это не только невозможно, но и бессмысленно. Представьте себе библиотеку для отображения географической информации. Хотите ли вы демонстрировать растительность, национальные, государственные или другие политические границы, автомобильные и железные дороги или реки? Надо ли показывать социальные и экономические данные? Отражать ли сезонные колебания температуры и влажности? Показывать ли розу ветров? Следует ли изобразить авиамаршруты? Стоит ли отметить местоположение школ, ресторанов быстрого питания или местных косметических салонов? “Показать все!” Для исчерпывающей географической системы это могло бы быть хорошим ответом, но в нашем распоряжении только один дисплей. Так можно было бы поступить при разработке библиотеки, поддерживающей работу соответствующих географических систем, но вряд ли эта библиотека смогла бы обеспечить возможность рисовать элементы карт от руки, редактировать фотографии, строить научные диаграммы и отображать элементы управления самолетами.

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

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

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

Мы решили использовать небольшие классы, содержащие несколько операций. Например, мы создали классы

Open_polyline

,

Closed_polyline

,

Polygon

,

Rectangle

,

Marked_polyline

,

Marks

и

Mark

вместо отдельного класса (который можно было бы назвать

Polyline

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

Shape

. Мы считаем, что использование небольших классов наиболее точно и удобно моделирует нашу область графических приложений. Отдельный класс, содержащий “все”, завалил бы пользователя данными и возможностями, затруднив понимание, усложнив отладку и снизив производительность.

14.1.2. Операции

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

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

Point

.