Какова настоящая причина для предотвращения защищенного членского доступа через класс основы/одноуровневого элемента?

ОБНОВЛЕНИЕ: этот вопрос был темой моего блога в январе 2010 года. Спасибо за отличный вопрос! См .:

https://blogs.msdn.microsoft.com/ericlippert/2010/01/14/why-cant-i-access-a-protected-member-from-a-deved-class-part-six /

Есть ли у кого-нибудь пример проблема, которая может быть вызвана предоставление MyDerived доступа к базам защищенные члены через переменную типа YourDerived или Base, но делает не существует уже при доступе к ним через переменную типа MyDerived или MySuperDerived?

Меня несколько смущает ваш вопрос, но я готов дать ему шанс.

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

Первая часть проста:

// Good.dll:

public abstract class BankAccount
{
  abstract protected void DoTransfer(BankAccount destinationAccount, User authorizedUser, decimal amount);
}

public abstract class SecureBankAccount : BankAccount
{
  protected readonly int accountNumber;
  public SecureBankAccount(int accountNumber)
  {
    this.accountNumber = accountNumber;
  }
  public void Transfer(BankAccount destinationAccount, User user, decimal amount)
  {
    if (!Authorized(user, accountNumber)) throw something;
    this.DoTransfer(destinationAccount, user, amount);
  }
}

public sealed class SwissBankAccount : SecureBankAccount
{
  public SwissBankAccount(int accountNumber) : base(accountNumber) {}
  override protected void DoTransfer(BankAccount destinationAccount, User authorizedUser, decimal amount) 
  {
    // Code to transfer money from a Swiss bank account here.
    // This code can assume that authorizedUser is authorized.

    // We are guaranteed this because SwissBankAccount is sealed, and
    // all callers must go through public version of Transfer from base
    // class SecureBankAccount.
  }
}

// Evil.exe:

class HostileBankAccount : BankAccount
{
  override protected void Transfer(BankAccount destinationAccount, User authorizedUser, decimal amount)  {  }

  public static void Main()
  {
    User drEvil = new User("Dr. Evil");
    BankAccount yours = new SwissBankAccount(1234567);
    BankAccount mine = new SwissBankAccount(66666666);
    yours.DoTransfer(mine, drEvil, 1000000.00m); // compilation error
    // You don't have the right to access the protected member of
    // SwissBankAccount just because you are in a 
    // type derived from BankAccount. 
  }
}

Dr. Попытка зла украсть ОДИН ... МИЛЛИОН ... ДОЛЛАРОВ ... с вашего счета в швейцарском банке была пресечена компилятором C #.

Очевидно, что это глупый пример, и очевидно, что полностью доверенный код может делать с вашими типами все, что угодно - полностью доверенный код может запускать отладчик и изменять код по мере его выполнения. Полное доверие означает полное доверие. Дон' На самом деле таким способом можно спроектировать настоящую систему безопасности!

Но я просто хочу сказать, что «атака», которая здесь сорвана, - это кто-то, пытающийся выполнить окончательный обход инвариантов, установленных SecureBankAccount, для прямого доступа к коду в SwissBankAccount.

Это отвечает на ваш первый вопрос. , Я надеюсь. Если это не ясно, дайте мне знать.

Ваш второй вопрос: «Почему SecureBankAccount также не имеет этого ограничения?» В моем примере SecureBankAccount говорит:

    this.DoTransfer(destinationAccount, user, amount);

Очевидно, что «this» относится к типу SecureBankAccount или к чему-то более производному. Это может быть любое значение более производного типа, включая новый SwissBankAccount. Разве SecureBankAccount не мог полностью обойти инварианты SwissBankAccount?

Да, безусловно! И из-за этого от авторов SwissBankAccount требуется , чтобы понимать все, что делает их базовый класс! Нельзя просто волей-неволей уйти из какого-то класса и надеяться на лучшее! Реализация вашего базового класса может вызывать набор защищенных методов, предоставляемых базовым классом. Если вы хотите унаследовать его, вам необходимо прочитать документацию для этого класса или кода и понять, при каких обстоятельствах будут вызываться ваши защищенные методы, и соответственно написать свой код. Деривация - это способ обмена деталями реализации; если вы не понимаете деталей реализации объекта, из которого вы производите, не производите его.

И, кроме того, базовый класс всегда записывается перед производным классом. Базовый класс не Они меняются на вас, и, вероятно, вы доверяете автору класса не пытаться украдкой сломать вас с помощью будущей версии. (Конечно, изменение базового класса всегда может вызвать проблемы; это еще одна версия проблемы хрупкого базового класса.)

Разница между этими двумя случаями заключается в том, что когда вы производите от базового класса, у вас есть поведение одного класса по вашему выбору для понимания и доверия. Это послушный объем работы. От авторов SwissBankAccount требуется точное понимание того, что SecureBankAccount гарантирует неизменность перед вызовом защищенного метода. Но они не должны понимать и доверять каждому возможному поведению каждого возможного класса родственников , который просто является производным от одного и того же базового класса. Эти ребята могут быть реализованы кем угодно и делать что угодно. У вас не будет никакой возможности понять какой-либо из их инвариантов перед вызовом, и, следовательно, у вас не будет возможности успешно написать работающий защищенный метод. Таким образом, мы избавляем вас от этого беспокойства и запрещаем такой сценарий.

И кроме того, у нас есть , чтобы вы могли вызывать защищенные методы на получателях потенциально более производных классов. Предположим, мы этого не допустили и сделаем вывод что-нибудь абсурдное. При каких обстоятельствах может быть вызван защищенный метод когда-либо , если мы запретили вызов защищенных методов на приемниках потенциально более производных классов? Единственный раз, когда вы когда-либо могли вызвать защищенный метод в этом мире, - это если вы вызывали свой собственный защищенный метод из запечатанного класса! Фактически, защищенные методы почти не никогда не могут быть вызваны, и вызываемая реализация всегда будет самой производной. Какой в ​​таком случае смысл «защищаться»? Ваш «защищенный» означает то же, что и «частный, и может быть вызван только из закрытого класса». Это сделало бы их менее полезными.

Итак, краткий ответ на оба ваших вопроса: «потому что, если бы мы этого не сделали, было бы вообще невозможно использовать защищенные методы». Мы ограничиваем вызовы менее производными типами, потому что в противном случае невозможно безопасно реализовать любой защищенный метод, который зависит от инварианта. Мы разрешаем вызовы через потенциальные подтипы, потому что, если мы не разрешаем это, то мы почти не разрешаем никаких вызовов .