Почему OpenGL имеет глобальные функции? - PullRequest
4 голосов
/ 30 января 2010

Почему openGL не объектно-ориентирован? Все обучают объектно-ориентированному программированию + шаблонам проектирования, но OpenGL имеет много глобальных функций. Разве это не плохой стиль?

Ответы [ 5 ]

17 голосов
/ 30 января 2010

Весь смысл низкоуровневого API состоит в том, чтобы сделать его как можно более минималистичным и переносимым. Придание ей объектно-ориентированной архитектуры не позволило бы этого:

  • Полиморфизм добавляет ненужные накладные расходы на вызов функции.
  • Это вынуждает вас использовать довольно сложное соглашение о вызовах, которое уменьшает мобильность.
  • Вы не можете обернуть объектно-ориентированную архитектуру, чтобы сделать ее процедурной, но вы можете сделать наоборот; поэтому имеет смысл сделать вещи максимально гибкими. Если хотите, написать объектно-ориентированную оболочку вокруг OpenGL тривиально.

Наконец, вам действительно следует усомниться в том, чему вас учили об ООП. Несмотря на то, что ваш колледж или университет может вам сказать, ООП не является панацеей от разработки программы. Есть очень веские причины, почему в C ++ STL нет абсолютно никакой объектной ориентации (и в большинстве случаев Boost).

Объектная ориентация полезна в некоторых случаях, но вы должны узнать, когда она полезна, а когда нет, и ни при каких обстоятельствах не следует верить, что все, что не является ООП, является «плохим стилем».

11 голосов
/ 30 января 2010

OpenGL

  • OpenGL должен поддерживать все платформы - в этом отношении нет ничего общего с C - благодаря этому почти каждое устройство может использовать один и тот же API
  • OpenGL должен поддерживать все языки - в этом отношении нет ничего похожего на C - благодаря этому каждый язык, поддерживающий вызовы библиотек C (и почти все), может использовать OpenGL
  • OpenGL - это API, а не движок - он намеревается предоставить низкоуровневый интерфейс для графического оборудования, но достаточно высокий уровень, чтобы быть абстракцией к разным аппаратным средствам - C гораздо больше низкий уровень, чем C ++, ООП не низкий уровень
  • OpenGL - это основа для построения, а не полное решение - не существует единственно верного способа для написания графического кода, и OpenGL не должен нас ни к чему принуждать - будучи ООП это вынудит нас к их "колу"
  • OpenGL не привязан к какой-либо конкретной парадигме программирования - следовательно, мы можем заключить OpenGL в функциональный, логический или ООП-язык - или использовать его процедурно
  • OpenGL - это эффективность, и вы не можете добиться большей эффективности, чем путем прямого вызова функций. ООП так же эффективен, как и подходит для конкретной задачи.

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

И за это я восхваляю OpenGL, и за это я ненавижу Direct X.

Аминь.

Sidenote: Каждый обучает объектно-ориентированному программированию, потому что его легче всего понять. Это не единственная истинная парадигма. Есть функциональное программирование, логическое программирование, контрактное программирование и даже объектно-ориентированный способ написания на C. В компьютерной науке нет единственной правды. Что касается шаблонов проектирования, я могу назвать несколько из них, которые используются в архитектуре OpenGL. Плохой стиль? Я видел красивые программы на C, которые имели глобальные функции aaaaallll ...

8 голосов
/ 30 января 2010

В общем, OpenGL является объектно-ориентированным. Это просто реализовано на языке, который напрямую не поддерживает ООП. Но API является объектно-ориентированным: он состоит из ряда различных типов объектов и набора операций, определенных для каждого. И внутренности каждого типа объекта скрыты от пользователя. Он отвечает всем требованиям ООП. Так получилось, что он реализован на C, который не имеет удобного синтаксиса класса или метода-члена.

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

4 голосов
/ 30 января 2010

Ну, есть несколько причин.

  • Вы должны рассматривать контекст OpenGL как конечный автомат. В любой момент активен только один из них. Нет никакой разницы между тем, чтобы поставить маленький Opengl. Что бы ни было перед всем.
  • Speed, OpenGL был разработан как минимальный API
  • Если бы это было объектно-ориентированным, на каком языке вы бы это написали? C ++? Тогда все захотят написать сложные привязки. C ПУТЬ легче завернуть.
4 голосов
/ 30 января 2010

OpenGL был создан для и в C, и тогда ничего подобного не существовало. Даже сейчас они все еще хотят сохранить интерфейс C, потому что C по-прежнему широко используется.

Должны ли они поддерживать интерфейсы C и оболочки C ++, отказаться от C и просто использовать C ++ или сохранить интерфейс C? Я бы сказал, что последнее - лучшее решение: легко для них, не слишком сложно для нас.

Тем не менее, интерфейс OpenGL по общему признанию является грубым. Многие вещи были «предположены» как устаревшие, но, увы, они были перенесены на более позднюю дату.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...