Вы когда-нибудь видели дизайн с разумным использованием модификатора защищенного внутреннего доступа?

У меня нет, но я не говорю, что его нет.

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

// Я считаю, что это не субъективно, я на самом деле ищу ответ ;-)

 mynkow05 нояб. 2014 г., 20:39
Спасибо за этот вопрос. И +1 за «разумное» слово в нем.
 Pauli Østerø06 янв. 2011 г., 02:31
.Net Framework использует ALOT внутренностей :)

Ответы на вопрос(6)

Решение Вопроса

Я уверен, что вы можете придумать примеры, но за пять лет разработки на C # я не нашел для этого подходящего примера. Пример Джона К. прекрасно иллюстрирует предполагаемое использование модификатора, однако я думаю, что требования, которые приводят к этой ситуации, проблематичны. В примере с Джоном К. у класса есть «дружественный» доступ в сборке, и в целом это проблема, потому что эти классы, вероятно, «спрашивают», а не «говорят» (программирование не вежливо, лучше сказать, чем спросить). ). В каком случае у вас есть полезный расширяемый класс, который Друзья могут вызывать методом, а другие нет?

Другое использование будет для тестирования доступа (т.е. вы хотите, чтобы он был защищенным, но внутренним, чтобы ваши вызовы уровня сборки могли его вызывать). Это тоже проблемная ситуация - когда вы выставляете вещи как внутренние для тестирования, я думаю, что это запах проекта, с которым обычно может справиться внедрение зависимостей.

 Xorty06 окт. 2010 г., 21:41
Конечно, и я согласен.
 Xorty06 окт. 2010 г., 21:24
Я почему-то чувствую, что открытие «черного хода» для модульного тестирования может быть удобным, но это как-то вредит дизайну: - /
 John K06 окт. 2010 г., 22:59
Что касается открытия внутренних компонентов для тестирования, то здесь стоит отметить, что Microsoft предоставила атрибут, который позволяетinternal подвергаться другой сборке черезInternalsVisibleToAttribute bit.ly/9UkCZe
 Alex Lo06 окт. 2010 г., 21:25
Я против открытия его для тестирования, надеюсь, это было понятно.

Это просто для людей, которые хотят унаследовать от вашего типа, потому что они не работают в той же компании, что и вы. ;-)

Серьезно, однако, вопрос относится только к внутреннему ... мы знаем, почему вы используете защищенный, верно? Итак, почему внутренний? Вероятно, только когда вы знаете, что ваш тип обращается к некоторым ресурсам, которые доступны только в одной сборке. Является ли это реальным ресурсом или другим типом, которым вы не хотите делиться с миром.

Да, в ситуации наследования всякий раз, когда виртуальному или абстрактному члену класса был разрешен прямой доступ другим классам в той же сборке (внутренней) «дружественным» / доверенным способом, но также этот член мог быть переопределен производными классами во внешнем сборки (через защищенные).

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

Ни один из модификаторов не может сделать это.

Или рассмотрим обратные ситуации:

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

если тытолько использованиевнутренний тогда производные классы (в других сборках) не могут переопределить этот метод.

Assembly1.dll

// ------ Assembly file 1 .dll --------

// Allow my friends (internal) and derived classes (protected) to do this. 
public class A {
    internal protected virtual void YoBusiness() {
        //do something
    }
}


class B { // not a derived class - just composites an instance of A
    public B() {
        A a = new A();
        a.YoBusiness(); // Thanks friend for the access! 
    }
}

Assembly2.dll

// ------ Assembly file 2 .dll --------

class C : A {  // derived across assemblies
    protected override void YoBusiness() {
        // Hey thanks other guy, I can provide a new implementation. 
    }
}
 John K06 окт. 2010 г., 22:17
Вместо того, чтобы конкретный проект сам по себе, я вместо этого описал сценарий (общее использование для него, одинаково полезный), в дополнение к тому, что это. Пример кода обеспечивает подтверждение этого сценария, поэтому его легко обнаружить в любом проекте.
 Jeff Sternal06 окт. 2010 г., 21:25
Это описывает то, чтоprotected internal является, но не описывает фактическое использование для этого.

Я действительно должен был использовать это впервые в моей карьере сегодня! У меня есть архитектура плагинов с baseclases, и плагины выставляются только через класс фасадов. Единственный способ ограничить плагин для вызова только через faqade - сделать его внутренним защищенным, поскольку плагины, которые его переопределяют, находятся в других сборках, в то время как слой faqade находится в том же базовом классе.

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

ты когда-нибудь использовал это

Да вместе сInternalsVisibleTo для модульного тестирования.

Всеprotected или жеinternal члены увеличивают сложность, сцепление и, следовательно, снижение целостности абстракций. Вы можете подумать о реализации некоторых методов, внутренних или защищенных, но в целом использование внутренних или защищенных полей - очень плохая идея. Защищенные / внутренние поля «открывают» вашу реализацию абстракций для широкого диапазона классов и сильно усложняют будущие модификации.

Я не люблю такие слова, как "никогда" или же "не делайте«как руководство по проектированию, но мы определенно должны использовать по крайней мере»избежать«Предложение как общее руководство по дизайну.

Ваш ответ на вопрос