Обращаясь к этим методам, прикладная программа сможет создавать, сдвигать, поворачивать и отображать объект с помощью следующих операторов:
cube а;
a.rotate(45.0, 1.0, 0.0, 0.0); a.translate(1.0, 2.0, 3.0); a.render();Концептуально этот код предполагает, что, когда вызывается метод a.rotate(.. ), экземпляр объекта а сам "знает", как "поворачиваться". Можно считать, что, вызывая этот метод, прикладная программа посылает экземпляру а класса cube сообщение. Зная особенности графической системы OpenGL, несложно разработать программный код реализации методов rotate( ), translate( ) и пр. Тут следует отметить одну интересную особенность. Разработкой системы классов и прикладной программы, работающей с этими классами, могут заниматься разные специалисты. Более того, библиотека классов может быть создана в третьей организации и распространяться как коммерческий продукт, доступный любому желающему. Программист, разрабатывающий прикладную программу, нуждается только в описаниях классов и их методов, т.е. он должен располагать информацией о том, к какому результату приведет вызов того или иного метода класса, и его может совершенно не интересовать, как именно будет это выполнено.
Итак, задумаемся над вопросом, к какому результату должен привести вызов метода render ( ) или метода rotate ( ) класса cube в программе, работающей в среде системы OpenGL? Прежде всего, нужно четко представлять, что переход на объектно-ориентированное программирование в графической системе OpenGL означает отказ от режима немедленного вывода изображения. Каждый экземпляр какого-либо графического объекта существует в программе сколь угодно долго и в любой момент может быть изменен соответствующими методами. Одним из способов реализации таких "долгоживущих" экземпляров в OpenGL является использование дисплейного списка, но возможны и другие. Что для нас важнее всего, так это то, что после создания экземпляра объекта он где-то продолжает существовать в программе, причем его внутренняя структура может быть совершенно неизвестна прикладной программе.