Pourquoi une variable de membre privé peut-elle être modifiée par instance de classe?

Question

class TestClass 
{ 
    private string _privateString = "hello"; 
    void ChangeData() 
    { 
     TestClass otherTestClass = new TestClass(); 
     otherTestClass._privateString = "world"; 
    } 
} 

Ce code compile en C# et l'équivalent fonctionne en PHP, mais quelqu'un peut-il expliquer la raison pour laquelle otherTestClass._privateString peut être changé ici?

J'aurais pensé qu'une instance d'une classe ne devrait en aucun cas pouvoir changer une variable membre privée, et qu'essayer d'accéder à otherTestClass._privateString donnerait une erreur 'inaccessible en raison d'un niveau de protection'.

Ceci n'est cependant pas le cas, alors pourquoi l'instanciation d'un objet dans sa propre classe vous permet-elle d'accéder aux membres privés? Et devrait-il, cela ne rompt pas l'encapsulation dans une certaine mesure? Ou est-ce que je manque quelque chose d'évident?

• (Je ne demande pas si la conception de classe ci-dessus est une bonne pratique, se demandant à peu près la théorie derrière.)

Modifier - Merci pour les réponses et commentaires. Pour clarifier, je suis également intéressé de savoir si être capable de faire cela est considéré comme une caractéristique positive, ou si c'est un compromis nécessaire pour une meilleure vérification de compilation/clarté du code/parce que la plupart des autres langues le font de cette manière. Il me semble idéalement que le compilateur vous prévienne ou vous prévienne, mais je suis loin d'être un concepteur de langage. Tout exemple de comment cela pourrait vous permettre de faire quelque chose d'utile (sans violer l'encapsulation) qui serait autrement difficile ou impossible serait génial.

Answer 1

Les membres privés sont accessibles à tout code dans le texte du programme de cette classe (y compris dans les types imbriqués). Cela n'a rien à voir avec l'instance de la classe à laquelle vous avez affaire.

Je ne crois pas que cela viole l'encapsulation - l'API est toujours séparée de l'implémentation, mais l'implémentation "sait" sur elle-même, quelle que soit l'instance qu'elle regarde.

Je crois que dans d'autres langages ce n'est pas comment l'accessibilité fonctionne, mais c'est certainement pour C# et Java. (Java a des règles légèrement différentes sur ce qui peut accéder aux membres privés, mais le code traduit pour ce que vous avez écrit fonctionnerait toujours.)

Answer 2

Ceci est dû au fait que C# applique la confidentialité au niveau de la classe et non la confidentialité au niveau de l'objet.

La plupart des langages grand public appliquent la même politique, c'est-à-dire C#, C++ et Java. Je pense que la raison en est:

1) parce que les développeurs sont habitués à ce genre de politique; 2) parce que l'intimité au niveau de l'objet deviendrait beaucoup trop fastidieuse en échange de très peu d'avantages.