Почему частные виртуальные методы недопустимы в C#?

Замечу, что здесь есть два вопроса. В будущем вы можете подумать о публикации двух вопросов вместо того, чтобы объединять два вопроса в один. Когда вы часто комбинируете такие вопросы, то получается только первый ответ.

Первый вопрос: «Почему частные виртуальные методы недопустимы в C #?»

Вот аргументы против возможности «частных виртуальных методов»:

1. частные виртуальные методы полезны только тогда, когда у вас есть вложенный производный класс. Это полезный шаблон, но он встречается гораздо реже, чем ситуация с невложенным производным классом.

2. Если вы желаете ограничить возможность переопределения метода в невложенных производных классах, вы можете сделать это, ограничив способность невложенных классов быть производными от базового класса; сделать все конструкторы базового класса закрытыми. Следовательно, частный виртуальный компьютер не требуется для предотвращения переопределения; protected virtual достаточно, потому что только производные классы будут вложенными.

3. Если вы хотите ограничить возможность вызова метода в не вложенном производном классе, вы можете сделать этот метод внутренним виртуальным, а затем сказать своим коллегам, чтобы они не использовали этот метод.Раздражает то, что это не выполняется компилятором, но компилятор также не налагает никаких других семантических ограничений на то, как предполагается использовать метод; Правильная семантика - это ваше дело, а не компилятор, и вы должны обеспечить это с помощью соответствующих проверок кода. Следовательно, частный виртуальный компьютер не нужен для предотвращения звонков; внутренний виртуальный плюс обзор кода достаточно.

4. Этот шаблон можно реализовать уже с существующими частями:

    абстрактный класс C
   {
   частный int CF () {что угодно; }
   private Func  f;
   общественный C () {f = CF; }
   частный int F () {return f (); }
   частный класс D: C
    {
   частный int DF () {что угодно; }
   общественный D () {f = DF; }
    }
   

   Теперь у меня есть метод F, который фактически виртуален, но может быть «переопределен» только производными вложенными классами.

Так как в каждом случае используется защищенный, внутренний или защищенный внутренний, частный виртуальный сервер не нужен. Это почти никогда не бывает правильным поступком, поскольку вы уже должны быть привержены использованию шаблона вложенного производного класса. Итак, язык делает это незаконным.

Аргументами являются:

В реальном коде были случаи, когда я хотел, чтобы виртуальный метод был частной деталью реализации класса, который я хочу расширить как невложенными внутренними классами, так и вложенными внутренние классы. Необходимость принудительно установить инвариант, что внутренний метод не должен вызываться моими коллегами, досадна; Я бы хотел, чтобы компилятор реализовал это, чтобы мне не приходилось прыгать через сумасшедшие обручи, такие как создание поля типа делегата и т. Д.

Кроме того, это просто вопрос согласованности и ортогональности. Кажется странным, что две вещи, которые должны быть независимыми, - доступность и виртуальность - без необходимости влияют друг на друга.

Аргументы против этой функции довольно сильны. Аргументы в пользу довольно слабые. Следовательно, такой функции нет. Лично мне это очень нравится, но я полностью понимаю, почему команда дизайнеров никогда меня этим не занималась. Это не стоит затрат, и мне не хотелось бы не поставлять лучшую функцию, потому что мы потратили бюджет на функцию, которая почти никому не приносит пользы.

Второй вопрос: «Почему в C # вы не можете переопределить частный виртуальный метод в производном невложенном классе?»

На это есть несколько причин.

1. Потому что вы можете игнорировать только то, что видите. Частный метод является частным элементом реализации базового класса и не должен быть доступен.

2. Потому что разрешение имеет серьезные последствия для безопасности. Помните, что в C ++ вы почти всегда компилируете код в приложение сразу. У вас есть исходный код для всего; с точки зрения C ++ в большинстве случаев все является «внутренним». В C # это совсем не так. Сторонние сборки могут легко получить доступ к общедоступным типам из библиотек и создать новые расширения для этих классов, которые затем можно будет беспрепятственно использовать вместо экземпляров базового класса.Поскольку виртуальные методы эффективно изменяют поведение класса, любой код, который по соображениям безопасности зависит от инвариантов этого класса, должен быть тщательно разработан, чтобы он не зависел от инвариантов, гарантированных базовым классом. Ограничение доступности виртуальных методов помогает гарантировать сохранение инвариантов этих методов.

3. Потому что разрешение дает еще одну форму проблемы хрупкого базового класса. C # был тщательно разработан, чтобы быть менее восприимчивым к проблеме хрупкого базового класса, чем другие языки объектно-ориентированного программирования.Если недоступный виртуальный метод может быть переопределен в производном классе, тогда эта частная деталь реализации базового класса становится критическим изменением, если оно изменено. Провайдеры базовых классов должны иметь право изменять свои внутренние детали, не беспокоясь о том, что они сломали производные классы, которые зависят от них; в идеале при изменении деталей реализации необходимо поддерживать только общедоступный документированный интерфейс к типу.