Во-первых, protected не является гарантией конфиденциальности, если только единственный расходный класс в вашей цепочке наследования не закрыт (т.е. все базовые классы являются внутренними для сборки). Любой разработчик, который НИЧЕГО знает об ООП, может получить свой класс и показать все свои внутренние возможности миру.
Использование internal для членов обычно решает эту проблему; только ваш код, расположенный в той же сборке, которую вы разрабатываете, может видеть внутренний элемент. Общедоступные дочерние элементы, которые вы выставляете для использования другими, могут быть получены извне сборки, но внутренности, которые вы хотите скрыть, все еще скрыты. Разработчики, создающие дочерние или другие объекты в одной сборке, должны сообщать вам о том, что они используют, если ваши внутренние компоненты действительно чувствительны с точки зрения времени выполнения. Помните, что protected internal означает защищенное ИЛИ внутреннее, не защищенное И внутреннее.
Во-вторых, protected обычно указывает на некоторый недостаток в дизайне класса, особенно если используются как защищенные, так и публичные. Если у вас есть секрет, но вы должны поделиться им со своими детьми, это не большой секрет, и, вероятно, он должен быть публичным. Если это действительно секрет, вашим детям нельзя доверять, потому что если вы не сделаете вазэктомию своим детям с ключевым словом sealed, вы не сможете помешать им рассказать своим детям, которые больше не думают, что это большая часть секрет и поделись им со своей семьей или с миром.
Использование protected не страшно, оно просто не достигает того, для чего многие разработчики хотят его использовать; сделать внутреннюю часть класса доступной для «доверенных» людей, не рискуя раскрыть тонкие внутренние процессы. Это меньше контроля доступа и больше предложений доступа; используя защищенный, вы утверждаете, что этот метод полезен для детей, но сам по себе он не принесет много пользы не детям, или будет вреден для класса, если его разоблачить и неправильно использовать. Это почти то же самое, что вывесить на вашем дворе табличку с надписью «Моя дверь заперта, и я не собираюсь давать вам ключ, но у всех моих детей есть один». Это даже не половина, потому что «грабитель» может СДЕЛАТЬ одного из ваших детей и использовать их, чтобы отпереть дверь.
Распространенное и общепринятое использование protected для методов - для классов Template Method; это абстрактные классы, которые имеют общедоступный рабочий процесс скелета, но позволяют или требуют расширения определенных частей их функциональности, чтобы быть полезными. Эти части функциональности, как правило, очень сплоченные и второстепенные. Шаблон будет предоставлять общедоступную, не виртуальную «движущую функцию» и несколько дескрипторов «помощникам» как защищенные абстрактные или виртуальные методы. Это позволяет потребителям выводить класс и реализовывать помощников.
В этом случае вы, как правило, не заботитесь о дочерней реализации и не хотите ограничивать возможные решения; детям могут понадобиться общедоступные оболочки для вспомогательных методов, чтобы общаться с их зависимостями.
protected - также самый простой способ для юнит-тестирования внутренностей класса. Модульное тестирование - это хорошо, но если вы хотите написать тестовое устройство, которое использует метод, этот метод должен быть доступен извне класса. Частные просто не ходят. Внутренний обычно представляет аналогичную проблему. Чтобы вообще разрешить внутреннее тестирование, они должны быть по крайней мере защищены, чтобы вы могли получить класс ДЛЯ ЭКСПРЕСС-ЦЕЛЯ разоблачения внутренних органов. В противном случае вам понадобится какое-то действительно странное отражение, чтобы извлечь MethodInfo вашего частного метода и вызвать его (вместе с разрешениями SkipVerification CAS).