Salut
Comment fait on pour se brancher sur un evenement qui est definie dans un objet qui est en private dans une classe sans passer par un evenement intermediaire ?
thx ++![]()
Salut
Comment fait on pour se brancher sur un evenement qui est definie dans un objet qui est en private dans une classe sans passer par un evenement intermediaire ?
thx ++![]()
C'est très simple :-)
Tu ne peux pas ;-)
Si tu veux respecter l'encapsulation de ton modèle objet, tout ce qui est privé est innacessible de l'extérieur. Autrement dit si tu as le modèle suivant:
Il est parfaitement impossible de faire une sorte de "B.MyEvent" si tu ne redéfinie pas ton évènement dans la classe B.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 public class A { public event EventHandler MyEvent; } public class B { private A a = new A; }
La seule solution que je vois ça serait de passer par la réflexion, ce que je ne conseille absolument pas dans ce cas là. Ce qui est privé doit rester privé.
Je ne vois aussi que la réflexion pour essayer de récupérer l'ensemble des événement généré dans l'appli et de réagir à ton événement de l'objet privé.
Il est plus simple de passer par un événement intermédiaire![]()
Comme déjà cité précédemment. Tout ce qui est privé doit rester privé.
Si c'est privé c'est pour une bonne raison, celle que personne d'extérieur à l'objet en cours ne doit pouvoir y accèder et y mettre ses gros doigts partout ou faut pas...
Certes, le seul moyen d'accèder à un membre privé d'un objet est d'utiliser la Reflexion, mais ce n'est pas que déconseillé, cela va a l'encontre de tout développement objet, sauf cas exceptionnels, quand le modèle a été sciemment conçut comme cela.
Sinon utiliser des protected scope et hériter la classe est plus propre, mais pas toujours possible.
Actuellement le framework utilise la Reflexion pour accèder à des méthodes protégées pour la serialisation et le deserialisation par exemple, mais c'est le framework... il est normal que ces fonctions très spéciales ne soient accessible que par la classe elle meme et le framework par le biais de la Reflexion, mais en aucun cas ces fonctions ne devraient etre utilisées par d'autres objets...
Cette facon de faire peut engendrer des Effets de Bords particulièrement génant et encore plus difficiles à tracer, sans parler des bugs directement liés à ton objet.
De toutes les mauvaises idées, celle-ci fait partie des pires !
Thomas LEBRUN: MCAD.NET, MCTS (Win et Web), MCPD(Win et Web) & Microsoft MVP Client Application Development
WPF par la pratique, mon livre sur WPF ! (également disponible ici ou là)
A la découverte de .NET
On peut penser à du multithreading avec des événements spécifiques à chaque thread et un objet qui encapsule toutes les thread, un controleur en fait.En même temps, mettre un event en private, j'y vois pas trop d'intéret (mais bon, j'y ai pas réflechi plus que ca non plus )
Dans ce cas on peut comprendre l'intéret de déclencher l'enevement d'un thread, qui a été encapsuler dans ce thread pour qu'ils ne soient pas accesibles par les autres.
Le probleme c'est que le private ne protege pas les champs d'un accès d'objets de meme types entre eux.
Un objet de type A, peut accèder aux champs privés d'un autre objet de type A, sans utiliser la Reflexion.
En revanche un objet de type B ne pourra pas y accèder sans faire appel à la Reflexion.
Donc ya un légé probleme dans ton exemple si tous les threads sont de meme types... s'ils ne sont pas tous de meme types en revanche oui ton exemple est correct, mais dans ce cas, on utilisera SCIEMMENT la Reflexion pour outrepassé les niveaux d'accessibilité. Quand on fait cela on sait qu'on ne provoquera pas d'effets de bords, car on a tout conçut soit meme (ou son équipe) Dans ce cas précis, la Reflexion n'est pas une faute de développement ou de conception.
En effet je pensais à des threads de type différent, j'ai oublié de le préciser.Donc ya un légé probleme dans ton exemple si tous les threads sont de meme types... s'ils ne sont pas tous de meme types en revanche oui ton exemple est correct, mais dans ce cas, on utilisera SCIEMMENT la Reflexion pour outrepassé les niveaux d'accessibilité. Quand on fait cela on sait qu'on ne provoquera pas d'effets de bords, car on a tout conçut soit meme (ou son équipe) Dans ce cas précis, la Reflexion n'est pas une faute de développement ou de conception.![]()
Partager