Discussion :

[TabrisLeFol]

Bonjour,

Même si j'ai réussi à l'implémenter dans de nombreux contextes, j'ai du mal à avoir une compréhension précise de ce pattern.

Un point qui me pose problème actuellement est le 'lien' entre la vue et le modèle. Dans de nombreux schémas, on peut voir que la/les vue(s) écoutent le modèle. D'un point de vue 'programmatique', cela signifie que la vue en question a un accès au modèle afin de s'enregistrer (design pattern Observable). Comment peut on permettre cela sans pour autant permettre à la vue de corrompre l'intégrité des données ?

D'avance merci


PS : Pour donner un exemple, soit une classe Data faisant partie du modèle. Celle-ci possède une méthode addListener et setPropertyX. Si la vue peut appeler addListener alors elle pourrait également appeler setPropertyX, ce qu'elle ne devrait pas faire...

[dahtah]

Je me pose exactement la meme question en ce moment. Dans le sens Vue vers Modèle, pas de problème (le controleur gère le transit des données). Mais dans le sens Modèle vers Vue, je ne saisi pas la subtilité. J'ai l'impression que le controleur est court-circuité. Donc, ma Vue a conscience des objets de la couche Modèle (ce qui est mauvais).
Désolé de pas pouvoir plus t'aider... Je suis dans le meme cas.

[hed62]

La vue doit pouvoir voir le modele, mais pas le modifier : il ne faut donner l'accès que aux getter des propriétés du Model.

[ndp]

salut,

... Si la vue peut appeler addListener alors elle pourrait également appeler setPropertyX, ce qu'elle ne devrait pas faire...

il faut raisonner en terme de roles. Les interactions entre Observer/Observable sont differents de l'interaction entre TonInterfaceMetier/ClientDeTonInterfaceMetier et tes classes peuvent participer a plusieurs interactions sous differents roles.

Dans une interaction avec un Observable, tu invoques addlistener, C'EST TOUT. Si tu veux retrouver ca, dans l'implementation, par exp, tu utilises les interfaces java, qui implementent tres bien les Roles.