2010-06-01 16 views
6

Je viens de commencer à jouer avec Observable, Observer et c'est la méthode update() et je ne peux pas comprendre ce que je devrais faire lorsque différentes actions appellent notifyObservers(). Je veux dire, ma classe Observable a quelques méthodes différentes qui appellent à setChanged() et notifyObservers() à la fin. Selon la méthode appelée, une partie de l'interface utilisateur (Swing) doit être mise à jour. Cependant, il n'y a qu'une seule méthode update() implémentée dans la classe Observer.Comment effectuer différentes opérations dans la mise à jour d'Observer() en Java?

Je pensais de passer quelque chose à la méthode notifyObservers() et ensuite je peux vérifier l'argument sur update() mais il ne me semble pas être un bon moyen de le faire. Même si c'était le cas, que devrais-je faire? Une chaîne avec une courte description de l'action/méthode? Un int, comme un code d'action/méthode? Autre chose?

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

Répondre

7

En général, vous devriez mettre à jour tout ce qui est observable lorsque vous appelez update(). Si ce n'est pas pratique, vous pouvez passer un conseil à 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 ont aucune connaissance de la présence de l'autre, ils peuvent être aveugles au coût ultime de l'évolution Une opération apparemment inoffensive 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 maintenus conduisent généralement à de fausses mises à jour difficiles à repérer.

Ce problème est aggravé par le fait que le protocole de mise à jour simple ne fournit aucun détail sur ce qui a changé dans le sujet. o 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'implémentation, ils disent:

" Eviter les protocoles de mise à jour spécifiques à l'observateur: les modèles push et pull. Les implémentations du modèle Observateur ont souvent pour objet de diffuser des informations supplémentaires sur le changement. Le sujet transmet cette information en tant qu'argument à Update. La quantité d'informations peut varier considérablement. À une extrémité, que nous appelons le modèle poussé, le sujet envoie aux 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 n'envoie que la notification la plus minime, et les observateurs demandent explicitement des détails par la suite. Le modèle de traction met l'accent sur l'ignorance du sujet vis-à-vis de ses observateurs, alors que le modèle de poussée suppose que les sujets connaissent les besoins de leurs observateurs. Le modèle push peut rendre les observateurs moins réutilisables, car les classes Subject font des suppositions sur les classes Observer qui peuvent ne pas toujours être vraies. D'un autre côté, le modèle d'attraction peut être inefficace, car les classes Observateur doivent déterminer ce qui a changé sans l'aide du sujet. "

3

Le deuxième paramètre à update() est de type Object, donc vous pouvez passer tout ce qui est approprié. Comme vous le constatez, l'approche est plutôt générale. En revanche, une classe qui maintient un EventListenerList peut obtenir un degré de sécurité de type à l'exécution lorsqu'elle est utilisée comme spécifié.