nes
> IGraphicsSystem* graphicsSystem
у тебя будет много вариантов рендеров?
Pushkoff
> > IGraphicsSystem* graphicsSystem
> у тебя будет много вариантов рендеров?
я даже предвижу будущее - будет флейм про то, как тормозят виртуальные функции :)
innuendo
черт
ладно я что нибудь другое придумаю
Использую толстые god-классы в качестве базовых, которые знают о классах-потомках.
Пихаю в базовый класс кучу данных, функций, проверок и прочей гадости.
Почему? Потому что удобно, а на красоту кода - плевать.
PagaN
> Почему? Потому что удобно
Мне интересно, а что именно удобно и в чем удобство?
Pushkoff
>у тебя будет много вариантов рендеров?
Возможно когда-нить захочу интегрировать поддержку фашистского D3D )
nes
> Возможно когда-нить захочу интегрировать поддержку фашистского D3D )
но до того времени ты будешь юзать 2 класса вместо 1, что согласись не очень удобно
PANDA
Почти все данные в одном месте. Не нужно создавать новый класс, чтобы добавить характеристику к объекту.
Не нужно приводить и проверять типы. Все методы получают GameObject и никаких проверок не нужно, что я передал алиена, а не ящик с патронами.
Если я пытаюсь запросить здоровье у ящика - это баг и его нужно править.
Основное удобство - пишется меньше кода, создается меньше классов, быстрее навигация.
Как я давно для себя решил - стили (техники, паттерны, идеологии и т.д.) программирования должны помогать, а не мешать.
Мне удобнее так, этого достаточно.
PagaN
> Мне удобнее так, этого достаточно.
Ты пробовал иначе?
PANDA
Пробовал, но мне удобнее так.
PagaN
> Основное удобство - пишется меньше кода, создается меньше классов, быстрее
> навигация.
это все временно
Pushkoff
>но до того времени ты будешь юзать 2 класса вместо 1, что согласись не очень удобно
Да класса 2, но реализация то одна.
Лишние заголовочные файлы имхо мешать не будут, если уж слишком их будет много, можно будет все ифейсы запихнуть в отдельную папку в проекте.
PagaN
А по памяти такой god object не сильно получается расточительным?
nes
> Да класса 2, но реализация то одна.
ну если придется расширять интерфейс то это придется делать в 2 местах
Pushkoff
Если есть поддержка нескольких рендеров, то полюбому предется править в нескольких местах.
И тут, ине кажется, не зависит наследуемся мы от общего интерфейса или нет.
Pushkoff
Будут другие задачи, будут другие решения. Пока так.
Покажешь свой?
nes
> А по памяти такой god object не сильно получается расточительным?
Зависит от количества объектов, разумеется.
У меня сейчас больше всего памяти занимают текстуры, данные для анимации и служебные структуры рендерилки.
Объекты занимают меньше одного процента от общего объема.
Тема в архиве.