Pourquoi les champs privés sont-ils privés pour le type et non pour l'instance ?

Question

En C# (et dans de nombreux autres langages), il est parfaitement légitime d'accéder aux champs privés d'autres instances du même type. Par exemple :

public class Foo
{
    private bool aBool;

    public void DoBar(Foo anotherFoo)
    {
        if (anotherFoo.aBool) ...
    }
}

Comme le Spécification C# (sections 3.5.1, 3.5.2) stipule que l'accès aux champs privés se fait sur un type, et non sur une instance. J'en ai discuté avec un collègue et nous essayons de trouver une raison pour laquelle cela fonctionne ainsi (plutôt que de restreindre l'accès à la même instance).

Le meilleur argument que nous ayons pu trouver concerne les contrôles d'égalité où la classe peut vouloir accéder à des champs privés pour déterminer l'égalité avec une autre instance. Y a-t-il d'autres raisons ? Ou une raison en or qui signifie absolument que ça doit fonctionner comme ça ou que quelque chose serait complètement impossible ?

Answer 1

Je pense qu'une des raisons pour lesquelles ça marche comme ça, c'est parce que les modificateurs d'accès fonctionnent à temps de compilation . En tant que tel, déterminer si un objet donné est ou non le actuel n'est pas facile à faire. Par exemple, considérez ce code :

public class Foo
{
    private int bar;

    public void Baz(Foo other)
    {
        other.bar = 2;
    }

    public void Boo()
    {
        Baz(this);
    }
}

Le compilateur peut-il nécessairement comprendre que other est en fait this ? Pas dans tous les cas. On pourrait argumenter que cela ne devrait pas compiler, mais cela signifie que nous avons un chemin de code où un membre d'instance privé de l'instance correcte n'est pas accessible, ce qui, à mon avis, est encore pire.

Le fait de n'exiger qu'une visibilité au niveau du type plutôt qu'au niveau de l'objet permet de garantir que le problème est traitable, et de faire en sorte qu'une situation qui semble être devrait travail en fait travail.

EDITAR : L'argument de Danilel Hilgarth selon lequel ce raisonnement est à l'envers a du mérite. Les concepteurs de langage peuvent créer le langage qu'ils veulent, et les auteurs de compilateurs doivent s'y conformer. Ceci étant dit, les concepteurs de langage ont un certain intérêt à faciliter le travail des auteurs de compilateurs. (Bien que dans ce cas, il est assez facile d'argumenter que les membres privés pourraient alors uniquement sont accessibles via this (de manière implicite ou explicite)).

Cependant, je pense que cela rend la question plus confuse qu'elle ne doit l'être. La plupart des utilisateurs (moi y compris) trouveraient inutilement contraignant que le code ci-dessus ne fonctionne pas : après tout, c'est mon données auxquelles j'essaie d'accéder ! Pourquoi devrais-je passer par this ?

En bref, je pense que j'ai peut-être exagéré le fait que ce soit "difficile" pour le compilateur. Ce que je voulais vraiment dire, c'est que la situation ci-dessus semble être celle que les concepteurs aimeraient voir fonctionner.

Answer 2

Parce que le but de le type d'encapsulation utilisé en C# et dans des langages similaires * vise à réduire la dépendance mutuelle de différents morceaux de code (classes en C# et Java), et non de différents objets en mémoire.

Par exemple, si vous écrivez du code dans une classe qui utilise certains champs dans une autre classe, alors ces classes sont très étroitement couplées. Cependant, si vous avez affaire à un code dans lequel vous avez deux objets de la même classe, alors il n'y a pas de dépendance supplémentaire. Une classe dépend toujours d'elle-même.

Cependant, toute cette théorie sur l'encapsulation échoue dès que quelqu'un crée des propriétés (ou des paires get/set en Java) et expose tous les champs directement, ce qui rend les classes aussi couplées que si elles accédaient aux champs de toute façon.

_{*Pour des précisions sur les types d'encapsulation, voir l'excellente réponse d'Abel.}

Answer 3

De nombreuses réponses ont déjà été ajoutées à ce fil de discussion intéressant, mais je n'ai pas trouvé la véritable raison pour laquelle il est nécessaire d'agir. pourquoi ce comportement est ce qu'il est. Laissez-moi faire un essai :

A l'époque

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 de l'information, qui n'était pas considéré à l'origine comme un concept propre à l'OO (mentionné pour la première fois en 1978), a été introduit dans Smalltalk : toutes les données (champs) d'une classe sont privées, toutes les méthodes sont publiques. Au cours des nombreux développements de l'OO dans les années 90, Bertrand Meyer a tenté de formaliser la plupart des concepts de l'OO dans son ouvrage de référence, intitulé Construction de logiciels orientés objet (OOSC) qui est depuis lors considéré comme une référence (presque) définitive sur les concepts OO et la conception des langages.

Dans le cas de la visibilité privée

Selon Meyer, une méthode doit être mise à la disposition d'un ensemble défini de classes (page 192-193). Cela donne évidemment une granularité très élevée de masquage de l'information, la fonction suivante est disponible pour les classesA etB et tous leurs descendants :

feature {classA, classB}
   methodName

Dans le cas de private il dit ceci : sans déclarer explicitement qu'un type est visible par sa propre classe, vous ne pouvez pas accéder à cette fonctionnalité (méthode/champ) dans un appel qualifié. C'est-à-dire que si x est une variable, x.doSomething() n'est pas autorisé. L'accès non qualifié est autorisé, bien sûr, à l'intérieur de la classe elle-même.

En d'autres termes, pour autoriser l'accès à une instance de la même classe, vous devez autoriser explicitement l'accès à la méthode par cette classe. C'est ce qu'on appelle parfois "instance-privée" ou "classe-privée".

Instance-privée dans les langages de programmation

Je connais au moins deux langages actuellement utilisés qui utilisent le masquage d'informations privé par instance par opposition au masquage d'informations privé par classe. L'un est Eiffel, un langage conçu par Meyer, qui pousse l'OO à l'extrême. L'autre est Ruby, un langage beaucoup plus courant de nos jours. En Ruby, private signifie : "privé à cette instance" .

Choix pour la conception de la langue

Il a été suggéré que l'autorisation de l'instance-private serait difficile pour le compilateur. Je ne le 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é et x.doSomething() ne l'est pas, le concepteur du langage a effectivement défini l'accessibilité par instance uniquement pour les méthodes et les champs privés.

D'un point de vue technique, il n'y a pas de raison de choisir une voie ou l'autre (surtout si l'on considère que Eiffel.NET peut faire cela avec IL, même avec l'héritage multiple, il n'y a pas de 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é des méthodes et champs privés au niveau de la classe.

Pourquoi C# n'autorise que l'encapsulation de classe et non l'encapsulation d'instance ?

Si vous regardez les fils de discussion sur Internet concernant l'encapsulation d'instance (un terme parfois utilisé pour faire référence au 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 désapprouvé. Cependant, si l'on considère que certains langages modernes utilisent l'encapsulation d'instance, au moins pour le modificateur d'accès privé, on peut penser qu'il peut être et est utile dans le monde de la programmation moderne.

Cependant, il faut reconnaître que C# a regardé de plus près C++ et Java pour la conception de son langage. Eiffel et Modula-3 étaient également dans le coup, mais compte tenu des nombreuses caractéristiques manquantes d'Eiffel (héritage multiple), je pense qu'ils ont choisi la même voie que Java et C++ en ce qui concerne le modificateur d'accès privé.

Si vous voulez vraiment connaître le pourquoi vous devriez essayer de mettre la main sur Eric Lippert, Krzysztof Cwalina, Anders Hejlsberg ou toute autre personne ayant travaillé sur le standard de C#. Malheureusement, je n'ai pas pu trouver de note définitive dans la version annotée de la norme C#. Le langage de programmation C# .

Answer 4

Ce n'est que mon opinion, mais de manière pragmatique, je pense que si un programmeur a accès à la source d'une classe, vous pouvez raisonnablement lui faire confiance pour accéder aux membres privés de l'instance de la classe. Pourquoi lier la main droite d'un programmeur alors que vous lui avez déjà donné les clés du royaume dans sa main gauche ?

Answer 5

La raison en est le contrôle d'égalité, la comparaison, le clonage, la surcharge des opérateurs... Il serait très délicat d'implémenter l'opérateur+ sur des nombres complexes, par exemple.