Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: имеет ли смысл реализовывать следующее...  (Прочитано 12181 раз)
0 Пользователей и 1 Гость смотрят эту тему.
bebabo
Помогающий

ru
Offline Offline

WWW
« : 21-05-2007 07:33 » 

представьте  игру -  несколько уровней, на которых персонаж, управляемый игроком, выполняет следующие действия:
1) при нажатии влево-вправо -  ходит туда-сюда
2) при нажатии Z - выполняет основное действие (например стреляет)
3) при нажатии X - выполняет дополнительное действие (например бросает гранату).
на всех уровнях количество действий постоянно, но если первый пункт будет на всех уровнях одинаков, то основное и дополнительное действия будут на каждом уровне различными.

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

другой вариант, до которого я додумался -
создаем базовый класс, в котором нет ничего кроме виртуальной функции action, где, в свою очередь, реализовано действие "ходьба". от этого класса наследуем классы - основное и дополнительное действие - в которых перегружаем функцию action - прописываем  в нем нужные нам действия. и таких наследников создаем по количеству уровней. т.е. если уровня три, получаем
1) базовый класс ходьба
2) наследник базового - основное движение уровня 1
3) наследник базового - доп. движение уровня 1
4) наследник базового - основное движение уровня 2
5) наследник базового - доп. движение уровня 2
6) наследник базового - основное движение уровня 3
7) наследник базового - доп. движение уровня 3
уф! создали ) теперь создаем вектор указателей на базовый класс. в векторе будет три объекта. на позиции 0 - объект базового класса, на поз. 1 - основное движение уровня 1, на поз. 2 - доп. движение уровня 1. при нажатии игроком на кнопку итератор этого вектора будет устанавливаться на нужное действие и выполняться в коде будет только один объект-функция.
например: игрок выбирает стрельбу - нажимает Z, итератор устанавливается в 1, и выполняется стрельба. хочу выполнить дополнительное действие - изменяется итератор, указывая теперь на дополнительное действие.
при переходе на новый уровень - объекты на позиции 1 и 2 заменяются.

как вы думаете - этот вариант извращение или в этом действительно есть смысл? т.е. насколько этот подход целесобразнее первого - будет ли поиск в таблице виртуальных функций быстрее, чем switch в первом варианте?
« Последнее редактирование: 21-05-2007 08:40 от bebabo » Записан

Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #1 : 21-05-2007 07:51 » 

свич быстрее, палюбасу.  И менее запутанная логика.

а  то, что много кода в case - так это решается дополнительными функциями или, на крайний случай, выносом кода в xxx.h и
Код:
case 2:
{
   #unclude "xxx.h"
}
break;
читабельность сохраняется )
Записан

nikedeforest
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 21-05-2007 08:15 » 

А я поддержу так называемый "другой вариант". СМысл в этом есть и полне нормальный.
« Последнее редактирование: 21-05-2007 08:24 от nikedeforest » Записан

ещё один вопрос ...
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #3 : 21-05-2007 09:00 » 

nikedeforest, не спорю, я своё мнение высказал.  Только во том варианте куча-куча классов намечается...
Записан

nikedeforest
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #4 : 21-05-2007 09:11 » 

ВСе быть может. Но ООП создано все же для облегчения проектирования. Давай посмотрим с другой стороны. ЗАхочет программмер добавить еще одно основное движение, к примеру, прыжок. В случае ООП мы вносим изменения в базовый класс, которые потом наследуются. Одного изменения достаточно. А вот сколько изменений придется добавиться в switch? И еще бы не забыть ничего Улыбаюсь. А если мы решим добавить что-то на том уровне, что-то на другом, не обалдеем ли мы бегать по этим кейсам и не забудим ли мы чего? Вто такая мысль.
Записан

ещё один вопрос ...
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #5 : 21-05-2007 10:20 » 

а вот тут требуется уточнение от автора ) , что он хочет -

1 вариант  -
  1 лвл = движение A  (скажем, прыжок)
  2 лвл = движение A-B (прыжок, с одновременным показыванием языка)
  3 лвл = движение A-B-C (прыжок, с одновременным показыванием языка и вращением вокруг продольной оси тела)

2 вариант  -
  1 лвл = движение A  (некий прыжок)
  2 лвл = движение B ( другой прыжок)
  3 лвл = движение C ( сапсем другой прыжок)


в 1м вариате классы (то есть движение постоянно дополняется) , во втором - свич
Записан

bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #6 : 21-05-2007 10:41 » 

...в 1м вариате классы (то есть движение постоянно дополняется) , во втором - свич

правильно. я, конечно, понимаю, что так или эдак - особой разницы нет. в одном случае будет расти свич, в другом количество классов. но допустим, что уровней в игре, к примеру, сотня. т.е. чтобы выполнить то или иное движение для сотого уровня:
в первом случае - каждый раз при  нажатии клавиши будет иметь место перебор всех предыдущих пунктов свича,
а во втором случае - необходимые движения будут сформированны в переходе на новый уровень (т.е. в векторе указателей будут созданны объекты действий для конкретного уровня). и если бы не было поиска в таблице вирт. функций - кажется, что выигрыш будет однозначно за вторым методом, так как не нужно ничего искать, и мы сразу обращаемся к нужной функции.
в книжках пишут, что виртуальные функции - штука медленная (насколько я понимаю - именно из-за поиска в таблице). И мне интересно - в данном конкретном случае - насколько эффективным окажется второй подход?  т.е даст ли он вообще какой-нибудь положительный эффект, применительно к описанному выше варианту?
Записан

bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #7 : 21-05-2007 10:52 » 

nikedeforest, душой я тоже за второй вариант) он кажется мне красивее) а если учесть, что в каждом действии еще возможны вложенные свичи или if-else - контролирующие данное действие - то, мне кажется, что и по скорости второй вариант может выиграть по сравнению с первым.
Записан

Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #8 : 21-05-2007 10:57 » 

>>в книжках пишут, что виртуальные функции - штука медленная (насколько я понимаю - именно из-за поиска в таблице). И мне интересно - в данном конкретном случае - насколько эффективным окажется второй подход?  т.е даст ли он вообще какой-нибудь положительный эффект, применительно к описанному выше варианту?

нифига не медленная, нормальная )  . Нет там никакого поиска вообще то...

Но свич нужен будет уже для сотни классов, а не действий.

bebabo, если действия продолженные, то лучше классы. Уже решили ведь )
« Последнее редактирование: 21-05-2007 10:58 от Алексей1153++ » Записан

bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #9 : 21-05-2007 11:04 » 

свич в процессе самой игры не понадобится. разве только в моменты перехода с одного уровня на другой, когда нужно будет поменять объекты-функции в векторе. а в процессе самой игры - будет изменяться значение итератора в зависимости от нажатой клавиши: либо 0, либо 1, либо 2, и исполняться один единственный объект-функция.
« Последнее редактирование: 21-05-2007 11:07 от bebabo » Записан

v2
Помогающий

ua
Offline Offline

« Ответ #10 : 21-05-2007 14:11 » 

Массив функций ..
Записан
bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #11 : 21-05-2007 14:15 » 

Массив функций ..
это поправка к "исполняться один единственный объект-функция" ? нет, именно одна функция. та, на которую будет указывать итератор
Записан

bebabo
Помогающий

ru
Offline Offline

WWW
« Ответ #12 : 31-05-2007 07:42 » 

нашел еще один способ реализовать подобную ситстему - использовать вместо виртуальных функций boost::function.
только вот как-то странно - при попытке откомпилировать пример использования boost::function, компилятор ругается, что мол никакой function в boost нет.
Записан

Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines