Je remarque qu'il y a deux questions ici. Dans le futur, vous pourriez envisager d'afficher deux questions au lieu de la combinaison de deux questions en une seule. Lorsque vous combinez des questions de ce genre souvent ce qui se passe n'est que la première, on obtient une réponse.
La première question est "pourquoi êtes-privé virtuel des méthodes illégales en C#?"
Voici les arguments contre le "privé virtuel méthodes" fonctionnalité:
privé virtuel n'est utile que lorsque vous avez un imbriquée de la classe dérivée. C'est un bon modèle, mais bien moins courante que la non-dérivées imbriquées situation de classe.
Si vous le désir de restreindre la capacité de remplacer la méthode de la non-imbriquées les classes dérivées, vous pouvez le faire en limitant la capacité des non-classes imbriquées à dériver de la classe de base; faire toute la classe de base des constructeurs privés. Par conséquent privé virtuel n'est pas nécessaire de prévenir primordial; virtuelles protégées est suffisante, parce que les seules classes dérivées seront imbriquées.
Si vous désirez restreindre la capacité d' appeler une méthode dans un non-dérivées imbriquées classe puis vous pouvez faire de la méthode virtuelle interne, puis dites à vos collègues de ne pas utiliser cette méthode. Il est irritant pour avoir ce soit pas appliquée par le compilateur, mais le compilateur ne pas l'application de toute autre contrainte sémantique sur comment une méthode est censé être utilisé, d'obtenir le droit de la sémantique, c'est votre affaire, pas le compilateur, et que vous avez à faire valoir avec le code approprié examens. Par conséquent privé virtuel n'est pas nécessaire pour empêcher l'appelant; virtuel interne en plus des revues de code est suffisant.
-
Il est possible de mettre en œuvre ce modèle déjà avec des pièces existantes:
abstract class C
{
private int CF() { whatever; }
private Func<int> f;
public C() { f = CF; }
private int F() { return f(); }
private class D : C
{
private int DF() { whatever; }
public D() { f = DF; }
}
Maintenant, j'ai une méthode F qui est effectivement virtuel, mais ne peut être "remplacée" par des dérivés classes imbriquées.
Depuis, dans tous les cas soit protégé, interne ou interne protégée fait l'astuce, privé virtuel est inutile. Elle n'est presque jamais la bonne chose à faire, puisque vous avez déjà déterminé à l'aide de la dérivée imbriquée de la classe de modèle. Donc, la langue la rend illégale.
Les arguments sont les suivants:
Il ya eu des moments dans le code réel, quand j'ai envie d'une méthode virtuelle privé en détail de l'implémentation d'une classe que je veux être étendue à la fois par des non-nested classes internes et imbriquée à l'intérieur des classes. Avoir à appliquer l'invariant que la méthode interne de ne pas être appelé par mes collègues de travail est délicate; je voudrais qu'être appliquées par le compilateur sans avoir à me sauter à travers un fou cerceaux comme faire un champ de type délégué, etc.
Aussi, il n'y a tout simplement la question de la cohérence et de l'orthogonalité. Il semble étrange que les deux choses qui se doit d'être indépendant, de l'accessibilité et de virtualness -- avoir un effet sur les uns les autres inutilement.
Les arguments contre sont assez fortes. Les arguments sont bien faibles. Par conséquent, aucune fonctionnalité. Je serais personnellement très envie, mais je comprends totalement pourquoi l'équipe de conception a jamais pris de moi sur elle. Ça ne vaut pas le coût, et je ne voudrais pas de ne pas expédier une meilleure fonctionnalité, car nous avons passé budget sur une fonctionnalité que les avantages ou presque.
La deuxième question est "Pourquoi en C# n'êtes-vous pas en mesure de remplacer un privé virtuel méthode dans un dérivé non-classe imbriquée?"
Il y a plusieurs raisons.
Parce que vous ne pouvez remplacer ce que vous pouvez voir. Une méthode privée est un privé détail de l'implémentation d'une classe de base et ne doit pas être accessible.
Car permettre à, qui a de graves conséquences sur la sécurité. Rappelez-vous, en C++, vous avez presque toujours compiler du code dans une application à la fois. Vous avez le code source de tout; tout ce qui est essentiellement "interne" du C++ point de vue la plupart du temps. En C#, ce n'est pas du tout le cas. Troisième partie les assemblées peuvent facilement obtenir au public les types de bibliothèques et de produire de nouvelles extensions pour les classes qui peuvent ensuite être utilisés de façon transparente en place d'instances de la classe de base. Depuis virtuel efficace des méthodes de modifier le comportement d'une classe, tout code qui dépend, pour des raisons de sécurité sur les invariants de cette classe doit être soigneusement conçu de sorte qu'ils ne dépendent pas des invariants garanti par la classe de base. La restriction de l'accessibilité des méthodes virtuelles permet de s'assurer que les invariants de ces méthodes sont maintenus.
Car permettre à, qui fournit une autre forme de la fragile de la classe de base problème. C# a été soigneusement conçu pour être moins sensibles à la fragile de la classe de base problème que d'autres langages à objets. Si un inaccessible virtuel méthode peut être redéfinie dans une classe dérivée, puis privé de détail de l'implémentation de la classe de base devient une modification de rupture si altérée. Les fournisseurs de classes de base doit être libre de changer de détails internes sans se soucier de l'excès qu'ils ont cassé les classes dérivées qui en dépendent; idéalement, le public, documentée d'une interface de type doit être maintenu lorsque les détails de mise en œuvre du changement.
