public против внутренних методов на внутреннем классе - PullRequest
81 голосов
/ 02 апреля 2009
internal class Foo
{
  public void Fee()
  {
    Debug.WriteLine("Fee");
  }

  internal void Fi()
  {
    Debug.WriteLine("Fi");
  }
}

Я думаю, что Fee () и Fi () одинаково доступны, так как весь класс уже является внутренним. Я что-то пропускаю? Есть ли основания выбирать методы public или internal для таких случаев, как этот?

Ответы [ 7 ]

95 голосов
/ 03 апреля 2009

Объявление internal class Foo переопределит доступность метода public void Fee(), фактически сделав его внутренним.

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

35 голосов
/ 11 июля 2009

Единственное, чего здесь не хватает в ответе, - зачем вам это делать?

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

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

28 голосов
/ 03 апреля 2009

На самом деле - есть большая разница, если вы используете отражение; в частности, Silverlight может сильно расстроиться, если вы попытаетесь получить доступ к внутренним методам с помощью отражения, даже если бы у вас был доступ. Я видел случаи, когда мне приходилось делать метод общедоступным, чтобы заставить код работать в Silverlight, даже если он работает в обычном .NET.

Вы можете найти то же самое при частичном доверии к обычному .NET.

8 голосов
/ 19 апреля 2012

Это будет иметь значение, если вы хотите, чтобы ваш внутренний класс реализовал интерфейс. Метод, который является реализацией некоторого интерфейса, должен быть Public.

7 голосов
/ 03 апреля 2009

Вы правы, и Fee, и Fi будут одинаково доступны.

Из спецификации языка CSharp 3.0, под 3.5.2:

Домен доступности вложенного член M объявлен в типе T в пределах Программа P определяется следующим образом (отмечая, что сам М может быть тип):

• Если заявленный доступность М является общедоступной, домен доступности М является домен доступности T.

Таким образом, даже если Fee объявлен как открытый, он будет так же доступен, как и Foo (т.е. внутренний).

3 голосов
/ 03 апреля 2009

Согласно документации msdn ваш класс Foo не будет доступен вне вашей сборки, поэтому не имеет никакого значения помечать методы как внутренние или общедоступные; это даже не имеет значения, используя атрибут InternalsVisibleTo

1 голос
/ 20 декабря 2010

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

...