public против внутренних методов на внутреннем классе
internal class Foo
{
public void Fee()
{
Debug.WriteLine("Fee");
}
internal void Fi()
{
Debug.WriteLine("Fi");
}
}
Я думаю, что Fee() и Fi() одинаково доступны, так как весь класс уже является внутренним. Я что-то пропускаю? Есть ли причина выбирать методы public или internal для таких случаев, как этот?
7 ответов
internal class Foo декларация переопределит доступность public void Fee() метод, эффективно делая его внутренним.
В этом случае использование внутренних и публичных методов будет иметь тот же эффект. Единственная причина, по которой я бы выбрал общедоступные методы вместо внутренних методов в таком случае, заключается в том, чтобы облегчить переход к общедоступному классу в будущей версии, если вы решите это сделать.
Единственное, чего здесь не хватает в ответе - зачем это делать?
В некоторых библиотеках есть много классов, которые не предназначены для прикосновения потребителя библиотеки, но они должны наследовать интерфейсы, помеченные как общедоступные. Например, у меня есть библиотека с классом, который наследует интерфейс IComparer, но он используется только внутренне, и я не хочу загромождать публичный аспект моей библиотеки. Если я отмечаю реализованную функцию сравнения как внутреннюю, компилятор жалуется, что я не внедряю интерфейс IComparer.
Итак, как мне успешно реализовать интерфейс и в то же время предотвратить его доступность в публичном аспекте моей библиотеки? Отметьте класс как внутренний, но реализованную функцию как открытый.
На самом деле - есть большая разница, если вы используете отражение; в частности, Silverlight может очень расстроиться, если вы попытаетесь получить доступ к внутренним методам с помощью рефлексии, даже если бы у вас был доступ. Я видел случаи, когда мне приходилось делать метод общедоступным, чтобы заставить код работать в Silverlight, даже если он работает в обычном.NET.
Вы можете найти то же самое при частичном доверии к обычному.NET.
Это будет иметь значение, если вы хотите, чтобы ваш внутренний класс реализовал интерфейс. Метод, который является реализацией некоторого интерфейса, должен быть Public.
Вы правы, и Fee и Fi будут одинаково доступны.
Из спецификации языка CSharp 3.0, под 3.5.2:
Область доступности вложенного члена M, объявленного в типе T в программе P, определяется следующим образом (с учетом того, что сам M может быть типом):
• Если заявленная доступность M является общедоступной, домен доступности M является доменом доступности T.
Таким образом, даже если Fee объявлен как открытый, он будет таким же доступным, как и Foo (то есть внутренний).
Согласно документации msdn, ваш класс Foo не будет доступен вне вашей сборки, поэтому не имеет никакого значения помечать методы как внутренние или публичные; это даже не имеет значения, используя атрибут InternalsVisibleTo
Я бы пошел только с внутренними методами, если класс является внутренним. в случае, если вы передумаете и сделаете класс публичным, вы можете просто заменить текст, и все готово.