Всем привет!
Пишу игру-стрелялку. 
Player - класс игрока,  Point - класс точки в которой находится игрок.
Как лучше оформить метод перемещения игрока в точку: поместить в класс игрока или сделать класс менеджера перемещения или реализовать оба способа?



Это сообщение отредактировал(а) ivanoop - 10.12.2013, 11:33

ivanoop, первый вариант выглядит более естественно.

А чем плохо сделать Move без класса?

В чём преимущества


Это сообщение отредактировал(а) ivanoop - 10.12.2013, 12:16

Ну вот представь, что ты Игрок. Вариант 1: ты берешь себя защкирку и перемещаешь. Это выглядит для тебя правильным? Move не должен быть методом Player.

А что неправильного? 
Вот ты идёшь куда-то пешком. Кто тебя перемещает?

тоже верно, но мне не нравится. Move должен быть внешней сущностью на мой взгляд

Player должен предоставлять интерфейс (причем минимальный) для изменения своего состояния. Что у Player'а будет в этом интерфейсе для изменения позиции? Если он умеет только перемещаться из точки в точку (без каких либо дополнительных атрибутов, типа траектории или в крайнем случае просто скорости), то Move и будет таким интерфейсом. Сделать Move не членом класса это значит открыть этой самой функции Move внутренности Player'а, что бы она могла изменить позицию (которая хранится где то внутри Player'а), что является явным нарушением принципа инкапсуляции.

Другой вариант - когда Player вообще не хранит позицию, а за это отвечает кто то другой (типа мэнеджера игрового поля), так же возможен (и возможно это будет даже лучше, т.к. кто то должен отслеживать геометрическое взаимодейтсвие Player'ов друг с другом, а это лучше делать там, где есть полная картина игрового мира). В таком случае Move должен быть членом этого самого мэнеджера

3й вариант - Player хранит позицию, но перемещение описывается какой то сложной траекторией. В таком случае у Player'а есть примитив - переместится по заданному вектору (короткому), а собственно перемещением занимается внешний класс TrackPath (например). В таком случае метод Move будет и у Player'а и у TrackPath'а, и 2й будет использовать 1й для реального перемещения

тогда он должен быть в курсе внутренней реализации, это плохо.

Добавлено через 18 секунд
xvr написал уже...

вовсе не обязательно, достаточно иметь setPosition или что-то схожее.

и чем это от move отличается кроме названия?  

Добавлено через 1 минуту и 32 секунды


Добавлено через 6 минут и 23 секунды
вобщем все зависит от понятия "перемещения игрока в точку". 
у объекта всяко должен быть атрибут "позиция" и метод её изменения.
если это просто смена позиции, этого метода достаточно. если это процесс, то осуществляется в зависимости от задачи либо самим объектом, либо менеджером путем вызова упомянутого метода.

А почему player'а кто-то перемещает или даёт команду переместиться?
Разве он не сам решает и стремится куда-то попасть? Под влиянием своих внутренних алгоритмов (ну или решения игрока-человека).

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

Если взять труды одного из основоположников ООА и ООП - Гради Буча, то в данной методологии есть основной принцип. Идти от задачи, от жизни. 

В жизни у Вас что и кто умеет перемещать или перемещаться?

Давайте поразмышляем. Человек может перемещаться? Да. Его может, кто то перемещать? Да. Но это уже будет свойством другой(!) сущности. У человека могут быть доп. условия перемещения? Да. инвалид, только прыгает(ну типа мозгами поехал), ползёт(типа кругом война), произошёл взрыв гранаты рядом(воздействие на объект, вектора воздействия и силу имеем. а вот повреждения - опять же задача не ударной волны и не гранаты!!!  ) и т.д.. Т.е. способ перемещения будет у человека зависить от его внутрених текущих задач, от текущей обстановки, и от его возможностей. Кстати говоря он может принять решение пожертвовать собой и из положения лёжа, броситься на пули...по какой-то своей логике...

Есть ещё "пару" правил:
- не надо программировать ради программирования(только от задачи).
- не надо резать будущие возможности(читай потребности объекта) в угоду оптимизации или другой своей внутренней потребности(обращаю внимание ВАШЕЙ потребности, а не бизнес задачи!).
- не надо додумывать как программист на этапе ООА и ООП (типа а вот так будет круче, быстрее, правильнее и прочая ересь с точки зрения ОО)
- после нахождения сущностей от жизни, проигрывания сценариев по юзанью найденных сущностей и их интерфейсов(динамическая модель) - можно просчитать те объекты которые уже необходимы для оптимизационных дел. Например, при сканировании бд не имеет смысла тащить на уровне сущностей все данные из таблиц. Вы же делаете операцию поиска в таблицах(к примеру) или там сканирования - вот и необходимо уже на этапе осмысления с точки зрения оптимальности по скорости работать с "коллекциями", а не со списками объектов. 
- И т.д... 

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

удачи вам
(круглый)

Это сообщение отредактировал(а) kolobok0 - 13.12.2013, 00:03

Если игрок сам захотел переместиться, то пишем строку

Если игрока поместили в автомобиль и перемещают, пишем строку
Но надо как-то изменить положение игрока записанное в самом игроке. 
Поэтому в  реализации метода car.Move придется вызвать метод player.Move.
То есть опять игрок перемещается сам.

Это сообщение отредактировал(а) ivanoop - 13.12.2013, 09:19

Поэтому надо не метод Move иметь а свойство Position, которое простейшим образом реализуется через setPosition()/position()

налицо более одной системы координат

Добавлено через 1 минуту и 36 секунд
я к тому, что перемещают только автомобиль. игрок перемещается как следствие (т.к. его локальная СК связана не с глобальной, а с СК авто)