Правильный путь в ООП. Пример игры. Player :: walk или Map :: playerWalk?

Давайте предположим, что есть игра. Есть класс карты и класс игрока. Карта магазинов полей и полей магазинов игроков.
Что было бы правильным способом сделать в ООП. Когда методом, отвечающим за ходьбу игрока, будет Player :: walk или Map :: playerWalk?

Что касается первого примера (Player :: walk), кажется, что это правильный путь, и он похож на реальный — его игрок, который ходит,
однако он должен был бы получить доступ к полю назначения через экземпляр карты, проверить, может ли он пройти туда, удалить его из начального поля и добавить его в поле назначения, у меня сложилось впечатление, что игрок «слишком много знает».

4

Решение

В конечном счете, это вопрос дизайна, оба могут хорошо вписаться в парадигму ООП.

Я склонен размещать методы в классе, который имеет смысл с точки зрения семантики. В этом сценарии это означает Player::walkдо тех пор, пока карта не сделает что-то, чтобы заставить «игроков» двигаться (т. е. в игре с флипперами игровое поле заставляет шарик [aka ‘player’] двигаться), и тогда может быть более семантическим, чтобы этот объект вызывал, например, Board::movePlayer,

Вы должны передать экземпляр карты игроку, если вы идете за Player::walk дизайн. Таким образом, вы в конечном итоге Player::walk(Map &map /*more parameters here, maybe a direction or vector speed?*/),

Другая вещь, на которую следует обратить внимание, это то, что вы должны попытаться сказать больше чем ты просить. Это означает, что это скорее, чем:

//in Player::walk
if (map.cells[wantToWalkTo] == 0) {
map.cells[wantToWalkTo] = this.playerId;
}
//TODO: handle failed moves

Вы должны сделать что-то вроде:

bool moved = map.moveTo(position, this); //encapsulate the logic for moving a player to a position
//TODO: handle failed moves
3

Другие решения

Ваш экземпляр игрока не должен «знать» все эти вещи. Он может связываться с экземпляром Map через интерфейс. Человек может смотреть на свое окружение и видеть некоторые вещи, но не другие (например, может видеть стену, но не то, что за ней). Экземпляр Map может контролировать то, что видно, а что нет.

Псевдокод Python-ish:

class Player:
def __init__(self, Map, location):
"""Create a player, and tell them what Map they live on."""self.Map = Map
self.location = location

def walk(self, destination):
"""Try to walk to the destination."""path = self.Map.path_visible(location, destination)

if path:
self.location = destination

class Map:
def path_visible(self, location, destination):
"""Can a player at location see how to get to the destination?"""
1

Правильный подход ООП будет для карты, чтобы представить некоторый интерфейс, который позволил бы:

  1. Проверьте, не заполнено ли какое-либо поле / какой объект находится в этом поле
  2. Поместить объекты на карту / удалить их

Логика перемещения игрока должна быть полностью в классе Player. Поэтому проверка того, является ли поле цели доступным для игрока, пустым и т. Д. … должна обрабатываться игроком с использованием информации, предоставленной интерфейсом карты или другими классами. Рассмотрим, например, ситуацию, когда вы хотите позволить игроку проходить сквозь стены, ходить по воде или подобным предметам — меняется игрок, а не карта!

0
По вопросам рекламы ammmcru@yandex.ru
Adblock
detector