Прямой поток в зависимости от входящего динамического типа - PullRequest
0 голосов
/ 26 декабря 2009

У меня есть класс слушателя, который принимает события изменения графического интерфейса в одном методе.

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

Я хотел бы сделать много методов, таких как:

handleGUIEvent(EventChangedX event)
handleGUIEvent(EventChangedY event)

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

Я не хочу использовать оператор switch, так как это будет невозможно поддерживать.

Ответы [ 4 ]

0 голосов
/ 27 декабря 2009

Вот что я сделал до сих пор, и, кажется, это работает хорошо.

У меня есть несколько компонентов GUI, которые включены в один большой графический интерфейс, но эти компоненты (и их события) должны использоваться за пределами этого интерфейса.

Большой графический интерфейс использует шаблон наблюдателя и ему назначен GUIController. Интерфейс GUIController имеет метод handleEventName для каждого события.

handleEventX(RangeChange changed);
handleEventY(AlgorithmChange alg);

Субкомпоненты вместо этого используют фактические события, которые распространяются вплоть до большого GUI, который может сам обрабатывать события через операторы switch или передавать их GUIController, который может, в свою очередь, CALL для действия в GUI (передача сообщений, я думаю) *

0 голосов
/ 26 декабря 2009

GUIEvent должен предоставлять абстрактный метод типа

delegateEvent(EventListener el)

Каждый подкласс должен затем реализовать этот метод и вызвать обратный вызов определенного метода на EventListener. Таким образом, подклассы GUIEvent могут определять, что вызывать на EventListener, а два класса объектов между ними могут определять, какое действие выполнить. Это известно как двойная отправка . Он избегает switch заявлений и т. П.

Хотя я нарисовал это как EventListener, вызывающий GUIEvent.delegateEvent и вызывающий back в EventListener, нет причины, по которой не может быть третьего класса (скажем, EventReceiver). Таким образом, абстрактный метод на GUIEvent будет выглядеть так:

delegateEvent(EventReceiver er)

и EventReceiver будут реализовывать соответствующие методы, которые будут вызываться GUIEvent s.

0 голосов
/ 26 декабря 2009

Есть несколько вариантов:

  • Создание классов обработчиков и регистрация каждого обработчика на карте с типом (классом) события в качестве ключа. Таким образом, вы можете сделать один поиск на карте, чтобы получить обработчик.
  • Создайте метод, который называется handle + тип события, которое он обрабатывает (например, handleMouseClick). Используйте отражение, чтобы найти правильный обработчик.

Первый подход, вероятно, более прост (и требует гораздо меньше try-catch).

Создайте вспомогательный класс для этого. В вспомогательном классе вы также можете добавить поиск, который использует getSuperClass() в классе событий для обработки наследования событий.

Map<Class<?>, IHandler> map;

public IHandler handler (Event event)
{
    Class<?> current = event.getClass ();
    while (true)
    {
        handler = map.get (current);
        if (handler != null)
            return handler;

        if (current == null)
            break;

        current = current.getSuperclass ();
    }

    return new DummyHandler ();
}
0 голосов
/ 26 декабря 2009

Вы можете поместить знания о том, что делать, в различные подклассы Event GUI. Однако это децентрализовало бы компонент «контроллер» в стандартной парадигме модель-представление-контроллер.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...