Почему внутренняя защита не является более ограничительной, чем внутренняя?

Я хотел бы создать внутреннее авто-свойство:

internal bool IP { get; protected internal set; }

Я подумал, что можно сделать сеттер protected или protected internal - но я всегда получаю модификатор доступности , который должен быть более строгим, чем свойство. Разве это не так? Private здесь не помогает.

EDIT:
Возникает вопрос: как реализовать автоматическое свойство с помощью внутреннего геттера и защищенного сеттера?

Ответы

Ответ 1

Эффективно protected или internal, а не и. Он доступен и по производным классам и типам в той же сборке. Это распространенное заблуждение думать, что protected internal означает доступный только производным классам в той же сборке.

Ответ 2

На уровне .NET существуют два одинаковых, но разных уровня доступа:

  • FamilyAndAssembly: более ограничительный, чем защищенный или внутренний
  • FamilyOrAssembly: менее ограничительный, чем защищенный или внутренний

"protected internal" в С# означает FamilyOrAssembly; нет модификатора для FamilyAndAssembly.

Итак, ваш установщик protected internal менее ограничительный, чем свойство internal. Что вы можете сделать:

protected internal bool IP { internal get; set; }

Но тогда ваш сеттер менее ограничен, чем ваш получатель, что нечетно...

Другая (несколько эквивалентная) альтернатива:

internal bool IP { get; set; }

protected void SetIP(bool ip)
{
    this.IP = ip;
}

Ответ 3

Я бы рассмотрел этот обман, так как Эрик Липперт тоже сам СО, но он написал превосходное сообщение в блоге, которое рассматривает эту проблему.

Почему я не могу получить доступ к защищенному члену из производного класса, часть третья

В конечном счете, его ответ во многом такой же, как и те, которые даны плакатами здесь, но он рекламирует некоторые интересные аргументы в пользу desgin языка и реализации этих функций.

Ответ 4

Учитывая то, что упоминал Джон Скит (и комментарий пользователя59808), не достигнет ли этого желаемого результата?

protected internal bool IP { get; protected set; }

Ответ 5

protected internal менее ограничительный, чем protected или internal, потому что он позволяет как своим подклассам (protected), так и всем, что находится в одной и той же сборке (internal), получить доступ к чему-либо.

Ответ 6

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

Ответ 7

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

Ответ 8

модификатор доступности должен быть более строгим, чем свойство

Внутреннее является более ограничительным, защищенным: поскольку защищенные объекты можно увидеть (по подклассам) вне сборки.

Компилятор говорит, что нет смысла говорить, что set защищен (т.е. видим для подклассов вне сборки), когда все свойство IP является внутренним (то есть невидимым вне сборки).