Как заставить класс прослушивать PropertyChangeEvents, вызванный другими классами, но не этим классом? - PullRequest
0 голосов
/ 13 января 2009

Как описано в другом вопросе , у меня есть набор объектов Model и связанный набор объектов Panel, которые позволяют пользователю получать доступ к данным в объектах Model. Панели регистрируются как PropertyChangeListeners для Моделей, так что если что-то еще обновляет значение в Модели, она запускает PropertyChangeEvent, и Panel получает его и знает, как повторно синхронизировать его значения из Модели. (В настоящее время я наивно просто обновляю все значения, но это можно сделать более разумным, чтобы получить только измененное свойство.)

Все это имеет смысл, когда Модель обновляется каким-то произвольным, неизвестным источником, что происходит в моем приложении. Однако чаще всего свойства модели задаются самими панелями. В этом случае, теперь, когда я подключил Панели как PropertyChangeListeners для Моделей, мой код выполняет то, что не имеет смысла: после того, как Panel обновляет Модель, Panel получает PropertyChangeEvent из Модели и извлекает то же значение из Модель, которую она изначально отправила в Модель в первую очередь. Обновление не требуется, и в этом нет никакого смысла для разработки.

Итак, как мне зарегистрировать что-то как PropertyChangeListener, а затем сказать: «Не уведомлять меня о PropertyChangeEvents, когда я являюсь их источником?» (Обратите внимание, что я не могу ответить на этот вопрос, вызвав PropertyChangeEvent.getSource (); он выдаст мне мою модель, а не Panel, которая отправила значение в первую очередь; нет способа посмотреть на это и сказать, что изменило свойство .)

Ответы [ 2 ]

3 голосов
/ 13 января 2009

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

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

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

1 голос
/ 14 января 2009

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

... и это не имеет никакого смысла для дизайна ...

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

Более того, если вы сделаете, как описано, вы порвете с разделением модели и вида, что никогда не было хорошей идеей.

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

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