metody publiczne a metody wewnętrzne w klasie wewnętrznej

internal class Foo
{
  public void Fee()
  {
    Debug.WriteLine("Fee");
  }

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

Myślę, że Fee () i Fi () są jednakowo dostępne, ponieważ cała klasa jest już wewnętrzna. Czy coś przeoczę? Czy jest jakiś powód, aby wybrać publiczne lub wewnętrzne metody w takim przypadku?

internal class FooOświadczenie zastąpi dostępności tej public void Fee()metody, dzięki czemu skutecznie wewnętrzny.

W takim przypadku użycie metod wewnętrznych i publicznych przyniesie ten sam efekt. Jedynym powodem, dla którego wybrałbym metody publiczne zamiast metod wewnętrznych w takim przypadku, byłoby ułatwienie przejścia do klasy publicznej w przyszłej wersji, jeśli zdecydujesz się to zrobić.

Jedyne, czego brakuje w odpowiedzi, to dlaczego miałbyś to zrobić?

Niektóre biblioteki mają wiele klas, które nie są przeznaczone do dotykania przez konsumenta biblioteki, ale muszą dziedziczyć interfejsy oznaczone jako publiczne. Na przykład mam bibliotekę z klasą, która dziedziczy interfejs IComparer, ale jest używana tylko wewnętrznie i nie chcę zaśmiecać publicznego aspektu mojej biblioteki. Jeśli oznaczę zaimplementowaną funkcję Compare jako wewnętrzną, kompilator narzeka, że ​​nie implementuję interfejsu IComparer.

Jak więc z powodzeniem wdrożyć interfejs i jednocześnie uniemożliwić dostęp do niego w publicznym aspekcie mojej biblioteki? Oznacz klasę jako wewnętrzną, ale zaimplementowaną funkcję jako publiczną.

Właściwie - jest duża różnica, jeśli używasz odbicia; w szczególności Silverlight może się bardzo zdenerwować, jeśli spróbujesz uzyskać dostęp do metod wewnętrznych poprzez odbicie, nawet jeśli miałbyś do nich dostęp. Widziałem sytuacje, kiedy musiałem upublicznić metodę, aby kod działał w Silverlight, mimo że działa na zwykłym .NET.

Możesz znaleźć to samo w przypadku częściowego zaufania w zwykłym .NET.

Miałoby to znaczenie, gdy chcesz, aby Twoja klasa wewnętrzna implementowała interfejs. Metoda będąca implementacją jakiegoś interfejsu musiałaby być Public.

Masz rację, zarówno Opłata, jak i Fi będą równie dostępne.

Ze specyfikacji języka CSharp 3.0, pod 3.5.2:

Domena dostępności zagnieżdżonego elementu członkowskiego M zadeklarowana w typie T w programie P jest zdefiniowana w następujący sposób (zauważając, że sam M może być typem):

• Jeśli zadeklarowana dostępność M jest publiczna, domena dostępności M jest domeną dostępności T.

Tak więc, nawet jeśli Opłata zostanie zadeklarowana jako publiczna, będzie tak samo dostępna jak Foo (tj. Wewnętrzna).

Zgodnie z dokumentacją msdn, twoja klasa Foo nie będzie dostępna poza twoim assemblerem, więc oznaczanie metod jako wewnętrznych lub publicznych nie ma znaczenia; nawet nie robi różnicy przy użyciu atrybutu InternalsVisibleTo

Użyłbym tylko metod wewnętrznych, jeśli klasa jest wewnętrzna. w przypadku, gdy zmienisz zdanie i upublicznisz klasę, możesz po prostu zastąpić tekst i gotowe.