Является ли плохой практикой программирования иметь «открытых» членов внутри «внутреннего» класса?

Question

Разве это не будет более конкретным и уместным, если я сохраню только "защищенные", "внутренние" и "частные" члены (поле, метод, свойство, событие) в классе, который объявлен как "внутренний"?

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

[Только для C #] Спасибо за ваш интерес.

Answer 1

Не обязательно.Если вы хотите неявно реализовать интерфейс, общедоступные члены более чем приемлемы.

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

Answer 2

Разумно предположить, что эти открытые члены все еще являются частью открытого интерфейса класса, даже если сам класс имеет внутреннюю область видимости.Когда я вижу internal на ученике, это говорит мне о "несколько изворотливом доступе к бэкдору, выражающем тесную связь, тогда как public все еще подразумевает правильные обязанности защитного программирования в моем уме.Это чисто концептуальное различие.

Answer 3

Вот что я делаю.Ничего не могу поделать, когда мой мозг думает, что «этот член должен быть доступен», мои пальцы безудержно начинают бить по публике.Нет такой проблемы, когда я объявляю класс.

Одно большое преимущество: рефакторинг, который делает внутренний класс общедоступным (или наоборот, предпочтительно), требует изменения только одного слова.И Microsoft тоже сделала это, в основном.

Answer 4

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

Answer 5

Единственная известная мне функциональная причина - неявная реализация интерфейсов. Все методы интерфейса должны быть помечены public, чтобы соответствовать интерфейсу. Это верно, даже если тип или интерфейс не являются публичными.

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

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

Answer 6

Я бы сказал, да, это плохая практика программирования.

Речь идет не только об управлении доступом. Это также делает код более модульным.

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

Объясняется с примером здесь: http://www.programmingincpp.com/private-versus-public-data-members-in-a-class.html

Answer 7

Я пытаюсь представить себе возможность изменения модификатора доступа к классу, когда я устанавливаю модификатор метода. Если метод должен быть внутренним, даже если класс общедоступный, я так и скажу. Если нет, то метод записывается как открытый.