Какие типы шаблонов дизайна облегчают события?

Question

Я работаю над игрой, и у меня тонна слушателей.

Например, когда язык игры меняется, LanguageManager отправляет событие languageChanged, которое вызывает все заинтересованные пользователи.элементы, чтобы получить новый текст и перерисовать себя.Это означает, что каждый заинтересованный элемент графического интерфейса реализует класс LanguageListener.

Еще одна вещь, которую я часто выполняю, это внедрение зависимостей.GuiFactory должен установить шрифты, чтобы он имел указатель на FontManager (который содержит массив шрифтов TTF), он также имеет GuiSkinManager, поэтому он может получать Image * в зависимости от скина игры.Правильный ли это способ сделать это?

Однако меня больше всего беспокоит слушатель и его огромное количество;особенно для графического интерфейса.Используемая им библиотека графического интерфейса почти полностью управляется слушателем.Большую часть времени я могу обходиться без ActionListeners, но у меня все еще есть вложенные ifs для if event.getSource () == button2 и т. Д.

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

Спасибо

Answer 1

Вместо одного интерфейса для каждого типа события, содержащего один обратный вызов (т. Е. LanguageListener), если бы вы следовали шаблону проектирования Observer, у вас был бы один интерфейс xObserver с обратным вызовом для каждого типа события.

class GuiElementObserver
{
public:
    void LanguageChangedEvent(...) {}
    void OtherEvent() {}
};

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

Что касается зависимостей, всякий раз, когда я выполняю рефакторинг кода, мне нравится использовать принцип единой ответственности (http://en.wikipedia.org/wiki/Single_responsibility_principle). Вы сказали, что GuiFactory нужно устанавливать шрифты ... Но действительно ли ответственность за установку шрифтов лежит на фабрике?

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

Answer 2

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

Для небольших приложений Mediator может быть обходным путем, если выдействительно ненавижу слушать события;)