OO Design, открытый / закрытый принципиальный вопрос

Я думаю, вы не должны позволять классу Game обрабатывать ввод-вывод. таким образом (блокирующий) метод TakeTurn скроет с игрового поля средства реализации. он может использовать другие объекты для связи с пользователем.

Все, о чем должен заботиться класс Game, - это состояние доски и ход. все игроки должны реализовать интерфейс для одного игрока и скрыть всю реализацию от игры.

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

Я думаю, что класс Game не должен беспокоиться о каких-либо реализациях классов Player, а также игнорировать пользовательский интерфейс.

Любой ввод пользователя должен обрабатываться классом HumanPlayer.

Интерфейс, который Игрок представляет для Игра, ортогонален поведению производных классов Игрок.

Тот факт, что реализация Принять поворот варьируется в зависимости от конкретного типа объекта Игрок, не должен вызывать беспокойства.

Я не уверен, что ты хочешь этого

public abstract class Player 
{
  int position;
  DecisionMaker decisionDependency;

  ...

  public void TakeTurn()
  {
    position += RollDice();
    GameOption option GetOptions(position);
    MakeDescion(option);
  }

  protected int RollDice()
  {
    //do something to get the movement
  }

  protected abstract void MakeDecision(GameOption option);

}

Public class ComputerPlayer : Player
{
  public ComputerPlayer()
  {
    decisionDependency = new AIDecisionMaker();
  }

  protected override void void MakeDecision(GameOption option)
  {
    decisionDependency.MakeDecision(option);
    //do stuff, probably delgate toan AI based dependency
  }
}

Public class HumanPlayer : Player
{
  public HumanPlayer()
  {
    decisionDependency = new UIDecisionMaker();
  }

  protected override void void MakeDecision(GameOption option)
  {
    decisionDependency.MakeDecision(option);
    //do stuff, probably interacting with the a UI or delgate to a dependency
  }
}

Я бы сказал, что класс Игра не должен заботиться о том, является ли он компьютерным игроком или человеком. Он всегда должен вызывать Принять поворот для следующего класса игрока. Если это игрок-человек, то ответственность за взаимодействие с пользователем и запрос у пользователя, что ему делать, возлагается на класс Игрок. Это означает, что он будет блокироваться, пока пользователь не примет решение. Поскольку обычно взаимодействие с пользовательским интерфейсом происходит в основном потоке приложения, важно только, чтобы блокирующий Принять поворот не блокировал приложение в целом, иначе пользовательский ввод не может быть обработан, пока Игра ожидает Принять поворот.

Если Game управляет игровым состоянием и, выполняя ввод-вывод, Game делает слишком много.

Вы хотите, чтобы игра была сосредоточена только на правилах, поворотах и ​​изменениях состояния. Игра не знает, кто такой игрок; он знает только, что у него есть игроки.

Вы хотите, чтобы игроки проверяли состояние игры и выполняли юридические действия во время своих ходов.

Люди-игроки и игра в целом обе используют общий пакет ввода-вывода, который показывает состояние игры и предлагает людям вводить данные.

Вы можете эффективно использовать Java Observable, сделав пакет ввода-вывода Observer игры. Таким образом, изменения состояния игры передаются в систему ввода-вывода для отображения или регистрации, или и того, и другого.

Вместо того, чтобы класс Игра вызывать Принять поворот для всех игроков, игроки должны вызывать Принять поворот в классе Игра, а класс Игра должен проверять, идет ли свой ход правильный игрок.

Это должно помочь решить проблему проигрывателя Пользователь и Компьютер.

У меня, вероятно, было бы не два класса HumanPlayer и ComputerPlayer, а один класс Player, который настраивается во время создания с правильной стратегией ввода.

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

Какой бы высокоуровневый класс ни создавал игру, он должен также создать два набора игроков (один человек, другой - смоделированный компьютером) с правильной стратегией ввода для каждого, а затем просто передать эти объекты игроков игровому объекту. Тогда класс Game будет вызывать метод TakeTurn только для заданного списка игроков для каждого нового хода.