Когда использовать EventListenerList вместо общей коллекции слушателей - PullRequest
13 голосов
/ 13 июля 2010

Когда я узнал, как запускать события в Java, я познакомился с EventListenerList. Когда я создаю своих собственных слушателей, я пишу слушателя так, чтобы он расширял EventListener, я сохранял их в EventListenerList, и мой метод fire проходил бы через слушателей событий, как это:

protected void fireChangeOccurred(Change change) {
    Object[] listeners = listenerList.getListenerList();
    for (int i = listeners.length-2; i>=0; i-=2) {
        if (listeners[i]==ChangeListener.class) {
            ((ChangeListener)listeners[i+1]).changeOccurred(change);
        }
    }
}

Теперь я рассматриваю код, который просто помещает слушателей в HashMap (может быть любой коллекцией), интерфейс слушателя не расширяет EventListener, и метод fire выглядит так:

protected void fireChangeOccurred(Change change) {
    for (ChangeListener listener : listeners) {
        listener.changeOccurred(change);
    }
}

Каковы преимущества использования EventListenerList вместо простого ведения собственного списка слушателей? Имеет ли значение только то, находятся ли слушатели в компоненте Swing - имеет ли это значение для потока диспетчеризации событий?

Ответы [ 3 ]

7 голосов
/ 14 июля 2010

EventListenerList имеет метод , getListeners(Class<T> t), специально для случая, когда вас интересует только один тип события.

Вот пример того, как его использовать:

protected void fireChangeOccurred(Change change) {
    for (ChangeListener listener:
         listenerList.getListeners(ChangeListener.class)) {
            listener.stateChanged(new ChangeEvent(this));
    }
}

Если вы решите сохранить собственную коллекцию слушателей, я рекомендую CopyOnWriteArrayList.

6 голосов
/ 14 июля 2010

Для меня главное преимущество EventListenerList состоит в том, что содержащий класс имеет (или может иметь) более одного типа слушателя.Многие компоненты Swing делают;тот, который вы просматриваете, может и не быть.Второй пример короче, но у него есть неявное ограничение дизайна.

3 голосов
/ 13 июля 2010

В наши дни нет огромных преимуществ. Просто небольшие оптимизации. Вот что говорит JavaDocs:

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

С современными JVM и коллекциями это действительно не имеет значения. Но то, что вы могли бы сделать со своей собственной реализацией, это предоставить способ инициировать изменения в EDT, если вы используете Swing - это было бы полезно.

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