Comment effectuer différentes opérations au sein de la mise à jour de l'observateur () en Java?

Question

Je viens de commencer à jouer avec Observable, Observer et méthode de la update() et je ne peux pas comprendre ce que dois-je faire lorsque différentes actions appellent notifyObservers().

Je veux dire, ma classe Observable a quelques méthodes qui font appel setChanged() et notifyObservers() à la fin. Selon la méthode appelée, une partie de l'interface utilisateur (Swing) doit être mis à jour. Cependant, il n'y a qu'une seule méthode de update() mis en œuvre dans la classe Observer.

Je pensais de passer quelque chose à la méthode notifyObservers() et je peux vérifier l'argument sur update() mais il ne se sent pas comme une bonne façon de le faire. Même si elle l'a fait, que dois-je passer? Une chaîne avec une courte description de l'action / méthode? Un int, comme un code d'action / méthode? Quelque chose d'autre?

Quelle est la meilleure façon de gérer cette situation?

Answer 1

en général, vous devez mettre à jour tout de l'observable lorsque vous recevez un appel à la mise à jour (). si ce n'est pas pratique, vous pouvez passer une allusion à notifyObservers ().

la bande-de-livre dit que l'une des conséquences du modèle d'observateur est:

"mises à jour inattendues. Parce que les observateurs ne connaissent pas l'autre présence, ils peuvent être aveugles au coût ultime de changer de sujet. Une opération apparemment anodine sur le sujet peut provoquer une cascade de mises à jour aux observateurs et leurs objets dépendants. de plus, les critères de dépendance qui ne sont pas bien définis ou entretenus conduisent généralement à des mises à jour parasites, qui peuvent être difficiles à trouver.

Ce problème est aggravé par le fait que le protocole simple de mise à jour ne fournit aucun détail sur ce qui a changé dans le sujet. Sans protocole additionnel à aider les observateurs découvrir ce qui a changé, ils peuvent être forcés de travailler dur pour en déduire les changements. " également en cours d'exécution, ils disent:

"Eviter les protocoles de mise à jour spécifiques d'observateurs. Les poussoirs et les modèles traction Implémentations du modèle d'observateur ont souvent fait l'objet de diffusion d'informations supplémentaires au sujet du changement Le sujet transmet cette information comme argument de mise à jour La quantité d'informations peut varier.. largement.

Dans un cas extrême, que nous appelons le modèle push, le sujet envoie des observateurs des informations détaillées sur le changement, qu'ils le veuillent ou non. À l'autre extrême est le modèle de traction; le sujet envoie rien que la notification la plus minime, et les observateurs demander des détails explicitement par la suite.

Le modèle de traction met l'accent sur l'ignorance de ses observateurs du sujet, alors que le modèle push suppose des sujets savent quelque chose au sujet des besoins de leurs observateurs. Le modèle push pourrait rendre des observateurs moins réutilisables, parce que les classes Sujet faire des hypothèses sur les classes d'observateurs qui pourraient ne pas être toujours vrai. D'autre part, le modèle de traction peut être inefficace, parce que les classes observateur doit déterminer ce qui a changé sans l'aide du sujet. «

Answer 2

Le second paramètre à update() est de type Object, de sorte que vous pouvez passer quoi que ce soit approprié. Comme vous le soulignez, l'approche est assez générale. En revanche, une classe qui maintient un EventListenerList peut obtenir un diplôme d'exécution saisir la sécurité lorsqu'ils sont utilisés comme spécifié.