C # Делегаты и События Дизайн / Архитектура

Question

Сценарий: игра с доской и несколькими фишками на ней.Классы: Доска , Плитка , Игрок и, конечно, Игра .Всякий раз, когда игрок нажимает на плитку, его счет увеличивается на 1. Доска создается внутри Game , а массив Tile создается внутри Совет .Моим первым вариантом легкого увеличения этой оценки было сделать открытый статический класс с открытым статическим полем (Score).Конечно, это довольно дилетантский.И казалось, что нарушает общий поток приложения.

После некоторых размышлений я изменил все, чтобы использовать события; Tile вызывает событие при нажатии; Board обрабатывает это событие и вызывает другое событие для основного Game класса. Игрок создается внутри Game ;когда Game обрабатывает событие, полученное от Board , оно выполняет PlayerOne (экземпляр Player ). Счет + = 1;

Если япросто идти вперед и использовать этот поток?Есть ли у вас какие-либо другие идеи архитектуры / дизайна, которые бы работали лучше?Почему ваши идеи будут работать лучше?Раньше я не интенсивно использовал события, сделанные по заказу, и чувствую, что все событие, порождающее еще одну идею, может быть немного ошибочным.Хотя издалека это выглядит как хороший поток.И это, безусловно, делает работу правильно.

Answer 1

То, что вы описали, выглядит (является) шаблоном проектирования наблюдателя.Игра должна «слушать» события с доски, доска должна слушать события с тайлов и т. Д.

Answer 2

Вы должны были предоставить некоторый код.

Должен ли я просто пойти дальше и использовать этот поток?

Зависит от того, как выглядят события.

Есть ли у вас какие-либо другие архитектурные / дизайнерские идеи, которые бы работали лучше?

Публикация / подписка является альтернативой.Но события .NET здесь работают нормально.

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

Хорошо хранить инкапсуляцию.Я бы сделал что-то вроде:

class Tile
{
    public event EventHandler Clicked = delegate{};
}

class Board
{
    private void OnTileClick(object source, EventArgs e)
    {
        var tile = (Tile)source;
        //doSome

        var args = new CustomEventArgs();
        CustomEvent(this, args);
    }

    public event EventHandler<CustomEventArgs> SomeEvent = delegate{};
}

public class SomeCustomEventArgs : EventArgs
{
}

Answer 3

Архитектура, которую вы, похоже, реализовали, хорошо подходит для этого сценария.

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

Архитектура наблюдателяЗдесь вы сможете легко добавлять или удалять игроков, плитки, доски.Если для «Игры» требовалось управлять несколькими досками, то простое добавление объекта и подписка на его выставленные события позволяет элегантно управлять этим.Это потому, что тайл не должен знать, что игрок существует.Точно так же игроку не нужно знать, что игра существует - он просто выполняет свою работу независимо.

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

Answer 4

Еще один способ взглянуть на это состоит в том, что доска зависит от игрока для правильной работы.Сколько игроков одновременно и добавляются ли игроки на игровое поле и с него во время игры?

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

Answer 5

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

Сказав это, я нахожу архитектуру вашего мероприятия довольно элегантной.