Не было бы более конкретным и уместным, если бы я только сохранил "защищенный", "внутренний" и "private" участников (поле, метод, свойство, событие) в классе, который объявлен как "внутренний"?
Я видел эту практику (имеющую "публичных" членов во "внутреннем" классе) в различном коде, поэтому просто хотел знать, что это плохая практика или имеет какую-то выгоду или преимущество.
[Только о С#] Спасибо за ваш интерес.
Не обязательно. Если вы хотите неявно реализовать интерфейс, то публичные члены более чем приемлемы.
В общем случае, если класс является внутренним, публичные члены не имеют большого смысла. Вам не повредит, так как вы не сможете подвергнуть класс строго типизированным образом вне модуля, в котором он определен, но если вы не подразумеваете реализацию интерфейса, то не так много преимуществ.
Разумно предположить, что эти публичные члены по-прежнему являются частью открытого интерфейса класса, даже если сам класс имеет внутреннюю область. Когда я вижу internal для члена класса, это говорит мне "несколько изворотливый доступ к бэкдору, выражающий жесткую связь, тогда как public по-прежнему подразумевает надлежащие защитные обязанности программирования в моем сознании. Это чисто концептуальное различие.
Спецификация internal в классе ограничивает область применения объявления public для членов, поэтому все ваши публичные члены действительно internal. Тем не менее, public намного меньше печатает, чем internal, поэтому моя нормальная идиома заключается в объявлении класса как internal и открытых методов как public. Я отмечаю только член как internal, если класс public, и я хочу ограничить некоторые члены одной и той же сборкой.
Что я делаю. Не могу с собой поделать, когда мой мозг думает, что "этот член должен быть доступен", мои пальцы неудержимо начинают забивать p u b l я c. Нет такой проблемы, когда я объявляю класс.
Одно большое преимущество: рефакторинг, который делает внутренний класс общедоступным (или наоборот наоборот), требует изменения только одного слова. И Microsoft тоже это делала, в основном.
Единственная функциональная причина, о которой я знаю, - это неявное внедрение интерфейсов. Все интерфейсные методы должны быть помечены public, чтобы соответствовать интерфейсу. Это верно, даже если тип или интерфейс не являются общедоступными.
Запрещая эту ограниченную ситуацию, мне действительно не нравится практика. Выполнение этого затрудняет grep для области публичной поверхности вашего приложения. Вместо этого вам нужно сделать более продвинутый поиск.
Кроме того, это беспокоит меня, вероятно, немного иррациональным образом, что участники отмечены как общедоступные, когда они действительно не являются.
Я пытаюсь представить возможность изменения модификатора доступа к классу при установке модификатора метода. Если метод должен быть внутренним, даже если класс является открытым, я скажу так. Если нет, то метод записывается как общедоступный.
Я бы сказал, что это плохая практика программирования.
Это не просто контроль доступа. Это также делает код более модульным.
Если потребитель данных объекта хочет некоторые из данных объекта, он вызывает метод getter. Если позже данные, которые должны быть возвращены, должны отличаться, программисту нужно только изменить код в одном месте, а не во всех местах, где эти данные были прочитаны (если участник был общедоступным). Это похоже на то, почему мы должны писать функции/методы и вызывать их вместо того, чтобы просто копировать и вставлять код о месте.
Объясняется здесь примером: http://www.programmingincpp.com/private-versus-public-data-members-in-a-class.html