2009-04-02 22 views
78
internal class Foo 
{ 
    public void Fee() 
    { 
    Debug.WriteLine("Fee"); 
    } 

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

Estoy pensando que Fee() y Fi() son igualmente accesibles ya que toda la clase ya es interna. ¿Estoy pasando por alto algo? ¿Hay alguna razón para elegir público o interno para los métodos en un caso como este?público vs métodos internos en una clase interna

+1

@EricLippert publicó su opinión hoy. http://ericlippert.com/2014/09/15/internal-or-public/#more-2353 – ScottS

Respuesta

94

La declaración internal class Foo anulará la accesibilidad del método public void Fee(), convirtiéndolo en interno.

En este caso, el uso de interno versus público en los métodos tendrá el mismo efecto. La única razón por la que elegiría los métodos públicos frente a los métodos internos en un caso como este sería facilitar la transición a una clase pública en una versión futura, si así lo desea.

+2

+1 ¡Mis pensamientos exactamente! – si618

2

De acuerdo con msdn documentation su clase Foo no será accesible fuera de su ensamblaje, por lo que no hace ninguna diferencia marcar los métodos como internos o públicos; incluso no hace la diferencia utilizando el Atributo InternalsVisibleTo

6

Está en lo cierto, tanto Fee como Fi estarán igualmente accesibles.

partir de la especificación CSharp Language 3.0, bajo 3.5.2:

El dominio accesibilidad de un anidado miembro M declaró en un tipo T dentro de un programa P se define como sigue (señalando que M en sí puede ser posiblemente un tipo ):

• Si el declarado accesibilidad de M es pública, el dominio accesibilidad de M es el dominio accesibilidad de T.

Por lo tanto, incluso si la tarifa se declara como pública, será tan accesible como Foo (es decir, interno).

25

En realidad, hay una gran diferencia si está utilizando la reflexión; en particular, Silverlight puede enojarse mucho si intenta acceder a los métodos internos a través de la reflexión, incluso si hubiera tenido acceso. He visto ocasiones en las que he tenido que hacer público un método para que el código funcione en Silverlight, aunque funciona en .NET regular.

Puede encontrar lo mismo con la confianza parcial en .NET regular.

+3

Estos son el tipo de detalles sucios que siempre me interesan. Sin embargo, en general, si alguien usa el reflejo para acceder a miembros ocultos en mis clases, no me preocuparé si es difícil para ellos. – ScottS

+1

@ScottS: algunas veces está reflexionando sobre sus * propios * tipos, es decir, donde normalmente tendría acceso al método interno, pero de repente no lo hace. –

32

Lo único que falta aquí en la respuesta es ¿por qué harías esto?

Algunas bibliotecas tienen muchas clases que no están destinadas para el consumidor de la biblioteca, pero deben heredar las interfaces marcadas como públicas. Por ejemplo, tengo una biblioteca con una clase que hereda la interfaz IComparer pero solo se usa internamente y no quiero saturar el aspecto público de mi biblioteca. Si marco la función de comparación implementada como interna, el compilador se queja de que no estoy implementando la interfaz IComparer.

Entonces, ¿cómo implemento con éxito la interfaz y al mismo tiempo evito que sea accesible en el aspecto público de mi biblioteca? Marque la clase como interna pero la función implementada como pública.

0

Iría solo con métodos internos si una clase es interna. En caso de que cambies de opinión y hagas pública la clase, simplemente puedes reemplazar el texto y listo.

7

Marcaría la diferencia cuando desee que su clase interna implemente una interfaz. El método que es una implementación de alguna interfaz, debería ser público.

Cuestiones relacionadas