De nombreuses réponses ont déjà été ajoutées à ce sujet intéressant, cependant, je n'ai pas tout à fait trouvé la vraie raison pour laquelle ce comportement est tel qu'il est. Laissez-moi essayer:
De mon temps
Quelque part entre Smalltalk dans les années 80 et Java au milieu des années 90, le concept d'orientation objet a mûri. Le masquage d'informations, qui n'était pas initialement considéré comme un concept uniquement disponible pour OO (mentionné pour la première fois en 1978), a été introduit dans Smalltalk car toutes les données (champs) d'une classe sont privées, toutes les méthodes sont publiques. Au cours des nombreux nouveaux développements d'OO dans les années 90, Bertrand Meyer a tenté de formaliser une grande partie des concepts OO dans son livre historique Object Oriented Software Construction (OOSC). qui a depuis lors été considéré comme une référence (presque) définitive sur les concepts OO et la conception du langage. .
En cas de visibilité privée
Selon Meyer, une méthode devrait être mise à la disposition d'un ensemble défini de classes (page 192-193). Cela donne évidemment une très grande granularité de masquage des informations, la fonctionnalité suivante est disponible pour classA et classB et tous leurs descendants:
feature {classA, classB}
methodName
Dans le cas où private
il dit ce qui suit: sans déclarer explicitement un type comme visible pour sa propre classe, vous ne pouvez pas accéder à cette fonctionnalité (méthode / champ) dans un appel qualifié. Ie si x
est une variable, x.doSomething()
n'est pas autorisé. L'accès non qualifié est bien entendu autorisé à l'intérieur de la classe elle-même.
En d'autres termes: pour autoriser l'accès par une instance de la même classe, vous devez autoriser l'accès à la méthode par cette classe explicitement. Ceci est parfois appelé instance-privé ou classe-privé.
Instance privée dans les langages de programmation
Je connais au moins deux langues actuellement utilisées qui utilisent le masquage d'informations privées d'instance par opposition au masquage d'informations privées de classe. L'un est Eiffel, un langage conçu par Meyer, qui pousse OO à ses extrêmes. L'autre étant Ruby, une langue beaucoup plus courante de nos jours. En Ruby, private
signifie: "privé pour cette instance" .
Choix pour la conception du langage
Il a été suggéré qu'autoriser l'instance privée serait difficile pour le compilateur. Je ne pense pas, car il est relativement simple d'autoriser ou d'interdire les appels qualifiés aux méthodes. Si pour une méthode privée, doSomething()
est autorisé etx.doSomething()
ne l'est pas, un concepteur de langage a effectivement défini l'accessibilité d'instance uniquement pour les méthodes et les champs privés.
D'un point de vue technique, il n'y a aucune raison de choisir l'une ou l'autre manière (surtout si l'on considère qu'Eiffel.NET peut faire cela avec IL, même avec l'héritage multiple, il n'y a aucune raison inhérente de ne pas fournir cette fonctionnalité).
Bien sûr, c'est une question de goût et comme d'autres l'ont déjà mentionné, certaines méthodes pourraient être plus difficiles à écrire sans la fonctionnalité de visibilité au niveau de la classe des méthodes et des champs privés.
Pourquoi C # n'autorise que l'encapsulation de classe et non l'encapsulation d'instance
Si vous regardez les fils Internet sur l'encapsulation d'instances (un terme parfois utilisé pour désigner le fait qu'un langage définit les modificateurs d'accès au niveau de l'instance, par opposition au niveau de la classe), le concept est souvent mal vu. Cependant, étant donné que certains langages modernes utilisent l'encapsulation d'instance, au moins pour le modificateur d'accès privé, vous pensez qu'il peut être et est utile dans le monde de la programmation moderne.
Cependant, C # a certainement regardé le plus dur C ++ et Java pour sa conception de langage. Alors qu'Eiffel et Modula-3 étaient également dans l'image, compte tenu des nombreuses fonctionnalités d'Eiffel manquantes (héritage multiple), je pense qu'ils ont choisi le même chemin que Java et C ++ en ce qui concerne le modificateur d'accès privé.
Si vous voulez vraiment savoir pourquoi vous devriez essayer de mettre la main sur Eric Lippert, Krzysztof Cwalina, Anders Hejlsberg ou toute autre personne qui a travaillé sur le standard de C #. Malheureusement, je n'ai pas trouvé de note définitive dans le langage de programmation annoté C # .