Должен ли я передавать информацию в Observer Events

1

У меня есть вход в Login. Я планирую заполнить это событие информацией, например:

// Class A.
Login login = new Login();
login.setUsername(userName);
observer.notifyEvent(login);

Идея состоит в том, чтобы класс B получил эту информацию.

Это плохая практика? Если да, то почему?

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

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

Теги:
design-patterns
observer-pattern

3 ответа

1
Лучший ответ

Не большая проблема. - Однако вы можете включить "отправителя" события в объект события, чтобы слушатель мог определить, откуда он пришел, и, при необходимости, может получить дополнительную информацию о состоянии из источника события.

0

Ну, вам, вероятно, нужно немного погрузиться в оригинальную книгу GoF. Для такой ситуации, когда разработчик заботится о разных компонентах, которые могут быть заинтересованы в разных типах событий, книга предлагает коллекцию subjects которая поддерживается ChangeManager.

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

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

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

Обращаясь к вашему примеру, гораздо лучше ввести тему " Login и не подписывать на нее какой-либо компонент, который не интересуется этим конкретным предметом.

0

Шаблон Observer позволяет отделить источник события от потребителей события.

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

Однако я не рекомендую использовать java.util.Observer который использует простой java.lang.Object как события, что означает, что вы должны проверить объект события через instanceof и применить его к соответствующему классу.

Я думаю, что лучше использовать реализацию Observer или Listener которая поддерживает общие типы, такие как Spring ApplicationListener или Guava EventBus, которые позволяют вам регистрировать Listener для событий определенного типа класса, например Login.class в вашем примере.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню