8.7. Графические объекты
когда не появляясь на экране. Выше уже говорилось о том, что такие объекты можно формировать, используя дисплейные списки, а в этой главе мы рассмотрим альтернативные подходы, основанные на использовании классов языка С++ или структурных типов языка С. Хотя существующие на сегодняшний день версии API OpenGL не поддерживают объектно-ориентированную технологию в явном виде, мы отнюдь не собираемся порывать с этой графической системой. Она будет использоваться по своему прямому назначению - формировать изображения объектов на экране. Программы, о которых пойдет речь в этом разделе, образуют своеобразную надстройку над OpenGL.
8.7.1. Методы, атрибуты и сообщения Создаваемые нами программы манипулируют данными. Данные могут представлять различную информацию - от чисел и строк символов до информации о составных геометрических объектах, сформированных в приложении. Традиционная процедурная технология программирования предполагает, что программист разрабатывает программный код, в котором манипулирование данными выполняется набором функций или процедур. Данные передаются в функцию через список аргументов и возвращаются аналогичным образом. Для того чтобы функция могла корректно оперировать с данными, она должна знать, как эти данные организованы. Рассмотрим, например, куб, который мы не раз использовали в предыдущих примерах. Уже не раз отмечалось, что его можно моделировать разными способами - с помощью указателей на вершины, списка ребер или списка вершин многоугольников граней. Программист, разрабатывающий прикладную программу, не очень-то хочет входить во все подробности конкретной реализации модели куба- он предпочитает рассматривать его как некую атомарную сущность или объект. Более того, прикладному программисту даже не желательно уделять внимание тому, каким образом формируется образ куба на экране, какая модель закрашивания и алгоритм заливки многоугольников при этом используются. Программист скорее предпочел бы, чтобы куб "сам знал", как отобразить себя на экране, т.е. чтобы алгоритм отображения уже был "встроен" в этот куб, а ему (программисту) оставалось бы только вызвать этот алгоритм в том месте прикладной программы, где этот куб следует включить в изображение. В определенной мере система OpenGL поддерживает такую точку зрения, используя для управления процессом формирования изображения параметры состояния графической системы. Например, цвет куба, его ориентация и освещение граней могут рассматриваться как компоненты текущего состояния и, следовательно, не зависеть от способа моделирования конкретного куба.