Программирование

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

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

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

Витрувий (Vitruvius)

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

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

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

14.1.1. Типы

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

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

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

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

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

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

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

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

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

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

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