Программирование. Принципы и практика использования C++ Исправленное издание - Бьёрн Страуструп
Шрифт:
Интервал:
Закладка:
1. Определите класс Arc, рисующий часть эллипса. Подсказка: fl_arc().
2. Нарисуйте окно с закругленными углами. Определите класс Box, состоящий из четырех линий и четырех дуг.
3. Определите класс Arrow, рисующий стрелки.
4. Определите функции n(), s(), e(), w(), center(), ne(), se(), sw() и nw(). Каждая из них должна получать аргумент типа Rectangle и возвращать объект типа Point. Эти функции должны определять точки соединения, расположенные на границах и внутри прямоугольника. Например, nw(r) — это левый верхний угол объекта класса Rectangle с именем r.
5. Определите функции из упр. 4 для классов Circle и Ellipse. Поместите точки соединения на границах и внутри этих фигур, но не за пределами окаймляющего их прямоугольника.
6. Напишите программу, рисующую диаграмму классов, похожую на ту, которая изображена в разделе 12.6. Программировать будет проще, если начать с определения класса Box, объект которого представляет собой прямоугольник с текстовой меткой.
7. Создайте цветную диаграмму RGB (поищите пример в вебе).
8. Определите класс Regular_hexagon (шестиугольник — это правильный шестисторонний многоугольник). В качестве аргументов конструктора используйте центр и расстояние от центра до угловой точки.
9. Покройте часть окна узорами в виде объектов класса Regular_hexagon (используйте не меньше восьми шестиугольников).
10. Определите класс Regular_hexagon. В качестве аргументов конструктора используйте центр, количество сторон (не меньше двух) и расстояние от центра до угла.
11. Нарисуйте эллипс размером 300×200 пикселей. Нарисуйте ось x длиной 400 пикселей и ось y размером 300 пикселей, проходящие через центр эллипса. Пометьте фокусы. Отметьте точку на эллипсе, которая не принадлежит ни одной из осей. Соедините эту точку с фокусами двумя линиями.
12. Нарисуйте окружность. Заставьте метку перемещаться по окружности (пусть она перемещается каждый раз, когда вы щелкаете на кнопке Next).
13. Нарисуйте матрицу цвета из раздела 13.10, но без линий, окаймляющих каждый квадрат.
14. Определите класс для прямоугольного треугольника. Составьте восьмиугольник из восьми прямоугольных треугольников разного цвета.
15. Покройте окно узорами в виде маленьких прямоугольных треугольников.
16. Покройте окно узорами в виде маленьких шестиугольников.
17. Покройте окно узорами в виде маленьких разноцветных шестиугольников.
18. Определите класс Poly, представляющий многоугольник, так, чтобы его конструктор проверял, действительно ли его точки образуют многоугольник. Подсказка: вы должны передавать в конструктор координаты точек.
19. Определите класс Star. Одним из его параметров должно быть количество точек. Нарисуйте несколько звездочек с разным количеством точек, разноцветными линиями и разными цветами заполнения.
Послесловие
В главе 12 мы играли роль пользователей классов. В этой главе мы перешли на один уровень вверх по “пищевой цепочке” программистов: здесь мы стали разработчиками классов и пользователями инструментов программирования.
Глава 14
Проектирование графических классов
“Польза, прочность, красота”.
Витрувий (Vitruvius)
Гавы, посвященные графике, преследуют двоякую цель: мы хотим описать полезные инструменты, предназначенные для отображения информации, и одновременно использовать семейство графических классов для иллюстрации общих методов проектирования и реализации программ. В частности, данная глава посвящена некоторым методам проектирования интерфейса и понятию наследования. Кроме того, мы вынуждены сделать небольшой экскурс, посвященный свойствам языка, которые непосредственно поддерживают объектно-ориентированное программирование: механизму вывода классов, виртуальным функциям и управлению доступом. Мы считаем, что проектирование классов невозможно обсуждать отдельно от их использования и реализации, поэтому наше обсуждение вопросов проектирования носит довольно конкретный характер. Возможно, было бы лучше назвать эту главу “Проектирование и реализация графических классов”.
14.1. Принципы проектирования
Каковы принципы проектирования наших классов графического интерфейса? Сначала надо разобраться в смысле поставленного вопроса. Что такое “принципы проектирования” и почему мы должны говорить о них, вместо того, чтобы заняться созданием изящных рисунков?
14.1.1. Типы
Графика — это пример предметной области, поэтому совокупность основных понятий и возможностей программист должен искать именно в ней. Если понятия предметной области представлены в программе нечетко, противоречиво, неполно или просто плохо, то сложность разработки средств графического вывода возрастает. Мы хотим, чтобы наши графические классы упростили работу пользователей.
Цель проектирования — отразить понятия предметной области в тексте программы. Если вы хорошо разбираетесь в предметной области, то легко поймете код, и наоборот. Рассмотрим пример.
• Window — окно, открываемое операционной системой.
• Line — линия, которую вы видите на экране.
• Point — точка в системе координат.
• Color — цвет объекта на экране.
• Shape — общие свойства всех фигур в нашей модели графики или графического пользовательского интерфейса.
Последнее понятие, Shape, отличается от остальных тем, что является обобщением, т.е. чисто абстрактным понятием. Абстрактную фигуру изобразить невозможно; мы всегда видим на экране конкретную фигуру, например линию или шестиугольник. Это отражается в определении наших типов: попытка создать объект класса Shape будет пресечена компилятором.
Совокупность наших классов графического интерфейса образует библиотеку, поскольку эти классы используются как все вместе, так и в сочетании друг с другом. Они должны послужить образцом при создании других графических фигур и строительных блоков для других классов. Поскольку все классы связаны друг с другом, мы не можем принимать проектные решения для каждого класса по отдельности. Все эти классы в совокупности отражают наше представление о графике. Мы должны гарантировать, что наша точка зрения является достаточно элегантной и логичной. Поскольку размер библиотеки ограничен, а область графических приложений бесконечна, надеяться на ее полноту нельзя. Следовательно, мы должны сосредоточиться на простоте и гибкости библиотеки.
На самом деле ни одна библиотека не способна моделировать все аспекты предметной области. Это не только невозможно, но и бессмысленно. Представьте себе библиотеку для отображения географической информации. Хотите ли вы демонстрировать растительность, национальные, государственные или другие политические границы, автомобильные и железные дороги или реки? Надо ли показывать социальные и экономические данные? Отражать ли сезонные колебания температуры и влажности? Показывать ли розу ветров? Следует ли изобразить авиамаршруты? Стоит ли отметить местоположение школ, ресторанов быстрого питания или местных косметических салонов? “Показать все!” Для исчерпывающей географической системы это могло бы быть хорошим ответом, но в нашем распоряжении только один дисплей. Так можно было бы поступить при разработке библиотеки, поддерживающей
