Tout en nettoyant un code aujourd'hui écrit par quelqu'un d'autre, j'ai changé le modificateur d'accès de est-ce normal? J'ai été codé dans .net depuis le début et je n'ai jamais rencontré ce problème, ni à ce sujet à ce sujet. J'ai peut-être trébuché dessus dessus avant, mais seulement "vaguement remarqué" et passez à autre chose. Quelqu'un peut-il expliquer ce comportement? J'aimerais connaître la "pourquoi" je peux faire cela. S'il vous plaît expliquer, ne me dis pas simplement la règle. Est-ce que je fais quelque chose de mal? J'ai trouvé ce comportement dans c # et vb.net. Le code semble tirer parti de la capacité d'accéder aux variables privées. L'inconvénient est que le programmeur a créé une grande plaque de spaghettis. sincèrement, public à privé sur une variable / membre / champ de classe. Je m'attendais à une longue liste d'erreurs de compilateur que j'utilise pour "refactoriser / retravailler / revoir" le code utilisé cette variable. Imaginez ma surprise quand je n'ai eu aucune erreur. Après avoir examiné, il s'avère qu'une autre instance de la classe peut accéder aux membres privés d'une autre instance déclarée au sein de la classe. Totalement excepté.
4 Réponses :
Ceci est "normal". Les membres privés sont privés à la classe, pas à l'instance particulière.
Mais j'accède à un membre privé de la classe à partir de deux instances différentes de la classe.
Comme il l'a dit: "Pas à l'instance particulière"
@Amissico: C'est ce que je veux dire: privé empêche l'accès de l'extérieur de la classe. L'accès est toujours autorisé à partir de la classe - à toutes les instances.
@Paul Baker: Veuillez fournir une référence. Où est la documentation? Je ne peux pas croire que je peux accéder à votre cœur privé comme cœur simplement parce que nous sommes deux cas de même classe humaine. Cela pourrait être vrai, mais j'ai besoin de la référence.
Comment est-ce (pour C #)? "Le privé - l'accès est limité au type contenant." [ msdn.microsoft.com/en-us/library /ba0a1yw2%28vs.80%29.aspx ] Notez que cela ne fait aucune mention d'instances du type.
La référence: "Les membres privés ne sont accessibles que dans le corps de la classe ou de la structure dans laquelle ils sont déclarés": msdn.microsoft.com/en-us/library/st8sy9xe.aspx
Domaine d'accessibilité à MSDN.MICROSOFT.COM/EN-US/LIBRARY/ZD74A9WW.ASPX . Mentionne qu'une classe de haut niveau ne peut pas accéder aux membres privés d'une classe imbriquée. Une classe imbriquée peut accéder aux membres privés de sa classe de niveau supérieur. Il semble qu'une classe de haut niveau soit «imbriquée» en lui-même. Je me demande est-ce une question du compilateur.
Je ne crois pas que les références fournies expliquent cette question. Il ne semble que expliquer les "erreurs attendues du compilateur" dans ma question.
Votre confusion ne concerne pas uniquement votre classe FOO et son _int et _foo membres? Ensuite, je ne vois pas comment les classes imbriquées sont pertinentes.
HM, vous dites que privé n'est pas privé entre les cas car le membre "décrit" la classe? Alors, comment puis-je garder les cas de se corrompre? Qu'est-ce qui empêche une instance de faire entourer ma propriété définie pour accéder à la variable privée qui détient la valeur de la propriété?
@Amissco - "Comment puis-je garder des instances de se corrompre?" ... Eh bien, vous écrivez la classe, n'écrivez pas simplement le code qui corrompt les autres instances! Il existe de nombreux cas dans lesquels vous devez accéder aux champs d'un autre instance (comparaisons d'égalité, par exemple). Le cas que vous devriez être plus intéressé est avec des membres protégés, qui ont des règles plus complexes, décrites ici: blogs.msdn.com/ericlippert/archive/2005/11/09 / ...
@Greg heech: il n'y a rien de "complexe" sur ce que cette entrée traite. Règles typiques d'héritage et d'accès.
@Greg Beech: Je n'ai aucun contrôle sur d'autres programmes de programmeurs ni de leurs implémentations. Si je marque un membre comme privé, je ne crois pas que l'autre instance devrait avoir accès à celui-ci.
@Greg heech: En ce qui concerne les comparaisons sur l'égalité, c'est peut-être là que j'ai remarqué ce comportement auparavant.
Si je n'ai pas remarqué ce comportement dans toutes mes années, je dois être très discipliné ou cela ne vient pas beaucoup. Je me suis dit que j'ai accepté cette réponse. : O)
@Amissico - "Je n'ai aucun contrôle sur d'autres codes de programmeurs ni de leurs implémentations" - mais sûrement si vous écrivez la classe et que les champs sont privés, peu importe ce que font les autres programmeurs? C'est tout à toi comme l'auteur. Sauf si vous dites que vous ne faites pas confiance aux personnes avec qui vous travaillez, qui pourrait également modifier la classe de ne pas vous tromper? C'est ce que les critiques et les tests sont pour vous assurer que vous avez bien compris!
@Greg heech: vous faites trop d'hypothèses. La classe que je travaille maintenant a été écrite d'au moins 4 personnes. Il y a plus de 4000 lignes de code. J'ai essayé depuis plus d'une semaine pour apporter des modifications, mais j'ai dû faire rouler le code arrière 4 fois. Je commence maintenant à comprendre ce qui se passe. Ils ont mis en œuvre une "file d'attente" dans la classe. Une instance de sa "classe" apporte des modifications à d'autres cas dans la file d'attente. L'instance actuellement «d'abord», fait ces changements. Qui est "premier" est déterminé par d'autres cas. Un désordre absolu. Aujourd'hui, par exemple, j'ai déplacé une ligne de code et j'ai cassé la classe.
@Greg heech: "Vous ne faites pas confiance à ... ne pas le tromper." Non, je dis que privé est privé. Si j'ai une instance d'une classe en soi, cette instance ne devrait absolument pas avoir accès à des informations «State» privées d'une autre instance. Cela n'a rien à voir avec la confiance. À mon avis, une instance ayant accès aux membres privés d'autres instances en elle-même viole complètement les "informations de cachette" (encapsulation). Si cela n'était pas important, deux cas de la même classe ne se limiteraient pas aux membres «public».
Ceci est le comportement attendu. Les classes imbriquées peuvent accéder aux membres privés de la classe de conteneurs.
Fred est la classe imbriquée et a accès, qui est attendu et le comportement dont je suis conscient. FOO n'est pas imbriquée et peut accéder à la mise en œuvre privée d'une autre FOO.
Vous avez dit:
S'il vous plaît expliquer, ne me dis pas simplement la règle.
Eh bien, voici mes deux cents.
Comme je le vois, le principe des membres privés d'une classe est qu'une classe peut être consciente à l'intérieur de sa propre mise en œuvre sans exposer cette mise en œuvre au monde extérieur. Ainsi, une instance d'une classe est parfaitement capable de comprendre la manière dont une autre instance de la même classe est mise en œuvre; Il n'est donc pas limité de tirer parti de cette connaissance de la mise en œuvre.
Comme pour les cas qui se manipulent mutuellement, je concéderai que cela est quelque peu inhabituel. Mais prenez par exemple des méthodes de construction statiques. Souhaitez-vous également restreindre ceux-ci de l'accès des membres privés d'instances? Si tel est le cas, vous avez impossible beaucoup de code utile. Sinon, il est difficile de savoir pourquoi les méthodes statiques devraient pouvoir accéder aux membres privés, mais les méthodes d'instance ne devraient pas.
En d'autres termes, le mot "privé" dans OOP n'est pas destiné à transmettre l'idée de la vie privée personnelle , comme chez les individus se cachent les uns des autres. Pensez plutôt à une classe comme une sorte de «membres uniquement» club , où il existe certaines façons de faire des choses que seuls les membres du club connaissent.
@Dan Tao: Merci. Comme je l'ai mentionné dans un commentaire, j'ai rarement traversé cette utilisation. Connaissez-vous de toute documentation décrivant pourquoi ce comportement existe? (Statique est un peu différent parce que je peux toujours accéder statique en dehors de la classe.)
Le problème de l'accès concerne l'endroit où le code accède aux membres privés et pas tellement de ce qu'il y accède.
Vous avez accès au champ Cela peut vous surprendre en outre que l'extension suivante à la classe code> Fred code> est également légale. . P> _foo._int code> dans le champ Définition de la classe foo code>, mais pas en dehors de celui-ci. p> Private Class Fred
Private _int As Integer
Private Sub Blah(ByVal foo As Foo)
foo._int = 9
End Sub
End Class
Après ma surprise initiale, j'ai testé cela pour vérifier ce que j'ai trouvé. Donc j'étais déjà surpris. : O)
Vous pouvez être surpris, mais C ++ a le même comportement.
@Vlad: vraiment? Cela fait longtemps que Borland 3.x, enfin, mais je ne me souviens pas de cela.
Essayez ceci avec n'importe quel compilateur C ++ moderne:
Classe X {Private: Int X; vide f () {x * px = nouveau x (); px-> x = 1; }};duplicaté possible de Pourquoi les champs privés sont-ils privés auprès de la Tapez, pas l'instance?
@Amissico Devrait-y-vote-vote-to-close-A-Duplicate-question - même-bien-sa-beaucoup de nouveau Je ne suis pas un fan de la règle, mais parfois je pense qu'il est préférable de laisser le q qui a reçu plus d'attention et de réponses.