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úblicos o internos para los métodos en un caso como este?
Respuestas:
La internal class Foodeclaración anulará la accesibilidad del public void Fee()método, convirtiéndolo efectivamente en interno.
En este caso, el uso de interno frente a público en los métodos tendrá el mismo efecto. La única razón por la que elegiría métodos públicos frente a métodos internos en un caso como este sería para facilitar la transición a una clase pública en una versión futura, en caso de que decida hacerlo.
Lo único que falta aquí en la respuesta es ¿por qué harías esto?
Algunas bibliotecas tienen muchas clases que no están diseñadas para que las toque 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 Compare 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.
En realidad, existe una gran diferencia si utiliza la reflexión; en particular, Silverlight puede molestarse mucho si intenta acceder a 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 normal.
Puede encontrar lo mismo con la confianza parcial en .NET normal.
Haría una diferencia cuando desea que su clase interna implemente una interfaz. El método que es una implementación de alguna interfaz, tendría que ser Público.
Tiene razón, tanto Fee como Fi serán igualmente accesibles.
De CSharp Language Specification 3.0, bajo 3.5.2:
El dominio de accesibilidad de un miembro anidado M declarado en un tipo T dentro de un programa P se define de la siguiente manera (teniendo en cuenta que M en sí mismo posiblemente sea un tipo):
• Si la accesibilidad declarada de M es pública, el dominio de accesibilidad de M es el dominio de accesibilidad de T.
Entonces, incluso si Fee se declara como público, será tan accesible como Foo (es decir, interno).
Según la documentación de msdn, 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; ni siquiera hace diferencia al usar Attribute InternalsVisibleTo
Iría solo con métodos internos si una clase es interna. en caso de que cambie de opinión y haga pública la clase, puede hacer un reemplazo de texto y listo.