Почему списки слушателей списки?

Question

Почему списки слушателей (например, в Java те, которые используют addXxxListener() и removeXxxListener() для регистрации и отмены регистрации слушателей) называются lists и обычно реализуются как Lists ? Не будет ли Set более подходящим, поскольку в случае слушателей есть

• Независимо от того, в каком порядке их вызывают (хотя вполне могут быть такие потребности, но они являются особыми случаями; обычные механизмы прослушивания не дают таких гарантий), и
• Нет необходимости регистрировать одного и того же слушателя более одного раза (если это приведет к тому, что один и тот же слушатель будет вызываться 1 раз или N раз, или это будет ошибка, это другой вопрос)

Это просто вопрос традиции? Наборы - это какие-то списки под капотом. Есть ли различия в производительности? Итерация по List быстрее или медленнее, чем итерация по Set? Занимает ли больше или меньше памяти? Различия, конечно, почти ничтожны.

Answer 1

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

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

Answer 2

Что за комплект? Должны ли все слушатели реализовывать equals и hashCode, чтобы использовался хеш-набор, или будет ли идентичен хеш-набор? Стоит ли использовать вариант добавления слушателя в список в два раза сложнее? Существует ли такой простой механизм, позволяющий обезопасить набор от добавления или удаления прослушивателей во время вызовов их обработчиков?

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

Answer 3

Вы совершенно правы. Слушатели должны быть добавлены в наборы. Как вы сказали, добавление слушателя более одного раза не имеет смысла. Кроме того, вы не будете полагаться на порядок слушателей, если вы используете наборы. И это самое главное: НЕ НАДО полагаться на это, если вы серьезно относитесь к разработке программного обеспечения, и каждый найденный нами принцип ведет нас к лучшему дизайну: изоляция, независимость, ответственность.

Каждый аспект, упомянутый здесь (многопоточность, производительность, ...), должен подчиняться самому себе в первую очередь, но может быть нарушен после, если у вас есть веские причины. И я имею в виду ОЧЕНЬ веские причины.

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