Запрос относительно дизайна основанной на классах текстовой игры приключения.

Похоже на сценарий, для которого я часто использую класс Command или класс Service. Например, я мог бы создать класс MoveCommand, который выполняет операции и координацию между уровнями и людьми.

Этот шаблон имеет то преимущество, что дополнительно усиливает принцип единой ответственности (SRP). SRP говорит, что у класса должна быть только одна причина для изменения. Если за перемещение отвечает класс Person, у него, несомненно, будет несколько причин для изменения. Разбивая логику Move off на отдельный класс, он лучше инкапсулируется.

Есть несколько способов реализовать класс Command, каждый из которых лучше подходит для разных сценариев. Командные классы могут иметь метод Execute, который принимает все необходимые параметры:

 public class MoveCommand {
    public void Execute(Player currentPlayer, Level currentLevel) { ... }
 }

 public static void Main() {
     var cmd = new MoveCommand();
     cmd.Execute(player, currentLevel);
}

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

 public class MoveCommand {
    public Player CurrentPlayer { get; set; } 
    public Level CurrentLevel { get; set; }
    public void Execute() { ... }
 }

 public static void Main() {
     var cmd = new MoveCommand();
     cmd.CurrentPlayer = currentPlayer;
     cmd.CurrentLevel = currentLevel;
     cmd.Execute();
}

Наконец, вы можете предоставить параметры в качестве аргументов конструктора в класс Command, но я откажусь от этого кода.

В любом случае, я считаю использование команд или служб очень мощным способом обработки операций, таких как Move.

Для текстовой игры у вас почти наверняка будет объект CommandInterpretor (или аналогичный), который оценивает вводимые пользователем команды. С таким уровнем абстракции вам не нужно реализовывать все возможные действия с вашим объектом Player. Ваш интерпретатор может передать некоторые набранные команды вашему объекту Player («показать инвентарь»), некоторые команды - объекту сектора, занятому в данный момент («список выходов»), некоторые команды - объекту уровня («переместить игрока на север»), а некоторые команды для специальных объектов («атака» может быть передана объекту CombatManager).

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

Избегайте эмоционального или интеллектуального зацикливания на том, как "правильно" что-то делать. Вместо этого сосредоточьтесь на делании. Не придавайте слишком большого значения коду, который вы уже написали, потому что любой или весь он может потребовать изменений для поддержки вещей, которые вы хотите сделать.

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

Уровень "содержит" все, что находится внутри него. Вы можете начать с него. Уровень не обязательно должен управлять всем, но все находится в уровне.

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

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

Это нормально, что уровень "владеет" игроком и что игрок имеет ссылку на свой уровень. Это "имеет смысл" с точки зрения ОО; вы стоите на планете Земля и можете влиять на нее, но она таскает вас по вселенной, пока вы копаете ямы.

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

Итак, во-первых, это хороший способ сделать это?

Совершенно верно!

Во-вторых, если глава делегата не представили так, как это было, я бы не думал об использовании таких 'Мероприятия'. Итак, что было бы хорошим способом реализовать это без использования обратные вызовы?

Я знаю много других способов реализовать это, но нет другого хорошего способа без какого-либо механизма обратного вызова. ИМХО, это наиболее естественный способ создания несвязанной реализации.