2009-10-30 12 views
5

La responsabilidad de la visibilidad de un método queda relegada a la clase que implementa la interfaz.¿Hay alguna razón por la que no pueda definir el modificador de acceso en un método o en una interfaz?

public interface IMyInterface 
{ 
    bool GetMyInfo(string request); 
} 

En C# set modificador de acceso público, privado o protegido antes de que el método GetMyInfo() genera el siguiente error: El modificador 'privado' no es válido para este artículo.

¿Hay algún motivo por el que no pueda definir el modificador de acceso en un método o en una interfaz?

(pregunta ya se le preguntó en francés here)

+0

posible duplicado de [Miembros no públicos para interfaces C#] (http://stackoverflow.com/questions/17576/non-public-members-for-c-sharp-interfaces) – nawfal

Respuesta

14

La interfaz define un contrato entre un objeto y los clientes que llaman a sus miembros. Ningún otro objeto puede acceder a un método privado, por lo que no tiene sentido agregarlo a la interfaz. Todos los miembros de una interfaz se consideran públicos por este motivo.

+0

¿por qué se salteó 'protected'? – UnKnown

4

En términos de OO, la encapsulación tiene que ver con el ocultamiento de datos. Eso significa que todo lo que sucede dentro de una clase depende de la implementación de la clase. Lo que significa que sería inútil hacer cumplir contractualmente a los miembros privados.

Sin embargo, la razón por la que uno usa interfaces es porque quiere asegurarse de que una clase cumpla con un contrato específico y exponga a varios miembros públicos de manera consistente.

+0

De hecho, ¿qué pasaría si, en la vida real, la interfaz física para conectar el cable a su monitor con su computadora no tuviera algunos pines (porque estaban perdidos/ocultos/privados)? Simplemente no funcionaría. Es por eso que incluso las interfaces virtuales deben estar completamente expuestas. –

10

Usted puede hacer realidad el método privado en la implementación de la clase, si realiza una implementación de interfaz explícita:

public interface IMyInterface 
{ 
    bool GetMyInfo(string request); 
} 

public class MyClass : IMyInterface 
{ 
    public void SomePublicMethod() { } 

    bool IMyInterface.GetMyInfo(string request) 
    { 
     // implementation goes here 
    } 
} 

Este enfoque significa que GetMyInfo no será parte de la interfaz pública de MyClass. Que sólo se puede acceder mediante la emisión del ejemplo MyClass-IMyInterface:

MyClass instance = new MyClass(); 

// this does not compile 
bool result = instance.GetMyInfo("some request"); 

// this works well on the other hand 
bool result = ((IMyInterface)instance).GetMyInfo("some request"); 

Así, en el contexto de la interfaz, todos sus miembros serán públicas. Se pueden ocultar de la interfaz pública de una clase implementadora, pero siempre existe la posibilidad de realizar un tipo de conversión a la instancia y acceder a los miembros de esa manera.

+1

+1 por ese poco más de información. Sin embargo, nunca he entendido por qué, o en qué circunstancias, este comportamiento es deseable (???) – Yoopergeek

+0

Sí, gracias por ese ejemplo –

+0

Gracias por señalar este vacío inusual. – warriorpostman

1

Todos los métodos de una interfaz deben tener el mismo nivel de acceso, para que la persona que llama pueda usarlos todos. Sin embargo, las interfaces también pueden ser internas (o como interfaz anidada privada).

Si necesita diferentes niveles de acceso, use una interfaz distinta.

0

Una definición privada en la interfaz haría:

  1. proporcionan ningún beneficio para el usuario de la interfaz (es privada después de todo)
  2. limitar la clase que implementa a tener que poner en práctica el método o propiedad
  3. fangosa la naturaleza conceptual de la interfaz con el detalle de puesta en práctica
  4. ser como una clase abstracta con un método privado (que no está permitido)
+0

Un modificador "privado" puede no ser útil, pero sí un modificador de acceso "interno". Hay situaciones en las que se desea permitir que el código externo pase referencias a una clase abstracta, pero no use todas sus características ni cree objetos que puedan sustituirse por ella. Hay situaciones en las que el gráfico de qué tipos de objetos deberían ser sustituibles entre sí no es un árbol, y por lo tanto solo se puede modelar con interfaces, en lugar de solo herencia. Cuando las dos situaciones se superponen, los métodos de interfaz interna serían útiles. – supercat

Cuestiones relacionadas