Что вы выбираете, защищенный или внутренний?

Question

Если у меня есть класс с методом, я хочу protected и internal. Я хочу, чтобы только производные классы в сборке могли вызывать его.

Поскольку protected internal означает protected или internal, вам придется сделать выбор. Что вы выбираете в этом случае - protected или internal?

Answer 1

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

Вам действительно нужно объективно подумать о цели метода. Внутренняя доступность почти всегда кажется мне неправильной. Главным образом из-за моего опыта, который я пытался получить из элементов управления или классов в среде .NET, где я столкнулся с кирпичной стеной, потому что кто-то решил пометить класс или как внутренний. Первоначальный автор никогда не замечал, что отсутствие доступа к этому методу значительно усложнило реализацию подкласса.

EDIT

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

Answer 2

Я хочу, чтобы только производные классы в сборке могли вызывать его.

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

Я предполагаю, что последнее дешевле и проще. Я бы сделал это внутренним.

Answer 3

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

Answer 4

Это такое странное решение: protected internal значит protected ИЛИ internal. Для этого точного случая я бы использовал internal. Причина в том, что если нарушена инкапсуляция, я бы предпочел, чтобы это был я, а не кто-то под моим контролем

Answer 5

Я думаю, что ответ зависит от ваших потребностей. На вашем месте я бы сделал что-то вроде этого:

    public class YourClass
    {
       protected class InnerClass
       {
           internal void YourMethod()
           {
               // Your Code
           }
       }
    }