C++ motif d'observateur « bidirectionnel »

Question

J'ai lu sur la façon de mettre en œuvre MVC appropriée dans une application C++ et essentiellement venu au point qu'il ya 2 façons de mettre en œuvre cette:

• modèle d'observateur
• signal/fente

Cependant, dans les deux cas, les exemples que je lis tous suivent une structure dans laquelle le sujet peut changer et notifier l'observateur (s), mais l'observateur ne change jamais le sujet. Maintenant, ce cas pose quelques "problèmes". Disons que j'ai une classe appelée Text (un composant de modèle), une autre nommée TextEditor (un composant de GUI) qui affiche quelque fois «Text» ET devrait pouvoir la modifier et quelques autres classes qui peuvent modifier le ' Texte aussi. À droite, donc j'utilise un modèle d'observateur, faites de 'Text' le sujet et 'TextEditor' l'observateur. Pas de gros problème.

Si 'Text' est modifié d'une manière ou d'une autre, Text appelle Text :: notify() et mon TextEditor reflétera la modification. Bien. Maintenant, que se passe-t-il si j'utilise TextEditor pour modifier le texte? 'TextEditor' connaît le terme 'Text', donc il appelle quelque chose comme textInstance.setText (...) ... et à la fin de setText, les appels 'Text' notifient, et 'TextEditor' est notifié de un changement il s'est fait! 'Text' ne peut même pas envoyer une notification à tout le monde sauf à 'TextEditor' car ce n'est pas supposé savoir à propos de ses observateurs!

J'ai le sentiment que ce n'est pas juste, pas "propre" même des raisons de performance. Je parierais qu'il y a une meilleure façon de l'implémenter mais je suis coincé. Quelqu'un a des indices?

Je ne suis pas vraiment à la recherche d'une implémentation C++ pré-faite, mais plutôt d'une compréhension de la façon dont je devrais voir les choses correctement.

Answer 1

Le motif est propre. Vous faites maintenant l'hypothèse que TextEditor maintenant ce que setText est en train de faire et vous n'avez donc pas besoin d'être averti. Que faire si le texte a été gelé et refuse de se modifier lui-même. Le texte peut également être une sorte d'enregistreur qui ajoute n'importe quel nouveau texte et ajoute l'horodateur etc.

Donc, il est parfaitement clair que TextEditor "demande" au Text de faire quelque chose et vérifie ensuite le résultat. Ainsi, TextEditor n'est pas notifié pour une modification qu'il a faite lui-même mais pour la manière dont la modification demandée a été gérée.

Si vous avez vraiment problème de performance que vous pouvez faire pirater le modèle d'observateur de manière différente

• supprimer TextEditor comme observateur avant d'appeler envoyerTexte et readding il après
• si tous les appels sont synchrones: la prévention TextEditor de rafraîchissement automatique en définissant un attribut
• etc ...