Сообщение Re[2]: static or singleton быть или не быть? И как быть? от 22.09.2016 8:11
Изменено 22.09.2016 8:14 AlexGin
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, 0x00, Вы писали:
0>>было интуитивно понятно что экземпляр рендера должен быть один
MD>Очень опасное самоуспокоение
Но справедливое, если применяешь OpenGL!
MD>Скажем, завтра портируем для каких-нибудь гугло-очков или телефона с двумя экранами — и вдруг опа, на каждый экран надо свой рендерер. Или пишем какой-никакой юнит-тест, и надо подоткнуть псевдо-рендерер. А у нас везде MyRenderer::getInstance() натыкан. Будет больно.
Работая с OpenGL, убедился что именно такое решение — правильное!
Второй рендерер — не будет корректно работать в другом потоке или процессе!
Мы для этой цели — применяем мьютекс.
MD>Код не должен знать, сколько экземпляров объекта. Он должен пользоваться тем экземпляром, что передан снаружи.
Это вопрос дизайна архитектуры продукта.
Или на уровне дизайна, или на уровне реализации — следует запретить одновременное использование двух рендереров OpenGL.
MD>Здравствуйте, 0x00, Вы писали:
0>>было интуитивно понятно что экземпляр рендера должен быть один
MD>Очень опасное самоуспокоение
Но справедливое, если применяешь OpenGL!
MD>Скажем, завтра портируем для каких-нибудь гугло-очков или телефона с двумя экранами — и вдруг опа, на каждый экран надо свой рендерер. Или пишем какой-никакой юнит-тест, и надо подоткнуть псевдо-рендерер. А у нас везде MyRenderer::getInstance() натыкан. Будет больно.
Работая с OpenGL, убедился что именно такое решение — правильное!
Второй рендерер — не будет корректно работать в другом потоке или процессе!
Мы для этой цели — применяем мьютекс.
MD>Код не должен знать, сколько экземпляров объекта. Он должен пользоваться тем экземпляром, что передан снаружи.
Это вопрос дизайна архитектуры продукта.
Или на уровне дизайна, или на уровне реализации — следует запретить одновременное использование двух рендереров OpenGL.
Re[2]: static or singleton быть или не быть? И как быть?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, 0x00, Вы писали:
0>>было интуитивно понятно что экземпляр рендера должен быть один
MD>Очень опасное самоуспокоение
Но справедливое, если применяешь OpenGL!
MD>Скажем, завтра портируем для каких-нибудь гугло-очков или телефона с двумя экранами — и вдруг опа, на каждый экран надо свой рендерер. Или пишем какой-никакой юнит-тест, и надо подоткнуть псевдо-рендерер. А у нас везде MyRenderer::getInstance() натыкан. Будет больно.
Работая с OpenGL, убедился что именно такое решение — правильное!
Второй рендерер — не будет корректно работать в другом потоке или процессе!
Мы для этой цели — применяем мьютекс.
Если тебе нужно два экрана, сначала следует отрендерить один, затем второй. Одновременно рендерить — это неправильно.
MD>Код не должен знать, сколько экземпляров объекта. Он должен пользоваться тем экземпляром, что передан снаружи.
Это вопрос дизайна архитектуры продукта.
Или на уровне дизайна, или на уровне реализации — следует запретить одновременное использование двух рендереров OpenGL.
MD>Здравствуйте, 0x00, Вы писали:
0>>было интуитивно понятно что экземпляр рендера должен быть один
MD>Очень опасное самоуспокоение
Но справедливое, если применяешь OpenGL!
MD>Скажем, завтра портируем для каких-нибудь гугло-очков или телефона с двумя экранами — и вдруг опа, на каждый экран надо свой рендерер. Или пишем какой-никакой юнит-тест, и надо подоткнуть псевдо-рендерер. А у нас везде MyRenderer::getInstance() натыкан. Будет больно.
Работая с OpenGL, убедился что именно такое решение — правильное!
Второй рендерер — не будет корректно работать в другом потоке или процессе!
Мы для этой цели — применяем мьютекс.
Если тебе нужно два экрана, сначала следует отрендерить один, затем второй. Одновременно рендерить — это неправильно.
MD>Код не должен знать, сколько экземпляров объекта. Он должен пользоваться тем экземпляром, что передан снаружи.
Это вопрос дизайна архитектуры продукта.
Или на уровне дизайна, или на уровне реализации — следует запретить одновременное использование двух рендереров OpenGL.