2012-03-21 15 views
5

He estado investigando sobre las interfaces y la explicación simple de un profano de lo que realmente es. al buscar en los mares de libros Por alguna razón, la gente adora utilizar explicaciones y jerga demasiado complejas para explicar conceptos verdaderamente simples (supongo que los hace sentir grandes) y tengo la intuición de que es lo mismo en este caso.interconexión: simplificado

por lo que pude entender, parece que las interfaces no son más que una forma de reservar los nombres de los métodos, su tipo de devolución, si existe, y el tipo y la cantidad de argumentos que aceptan. de modo que cuando una clase implementa una interfaz (o interfaces) se ve forzado a definir el cuerpo de cada método de la (s) interfaz (es). ¿Estoy en la nariz con este o necesito seguir cavando?

p.s. Sé que JavaScript no tiene soporte para interfaces, pero aún necesito entender el concepto porque hay bastantes lugares donde se muestra cómo emular en cierta medida.

+2

Probablemente el aspecto más importante de las interfaces es que el programador puede codificar en términos de interfaces. Por ejemplo, un programador puede codificar su sitio web de preguntas y respuestas, StackUnderflow, para analizar el contenido enviado por el usuario con una interfaz 'Parser' sin tener que preocuparse si es' MarkdownParser', 'LatexParser',' AsciidocParser', etc. Si cambia de opinión sobre en qué formato debe estar el contenido, puede cambiar una sola línea de código. Mientras la clase que elija implemente la interfaz 'Parser', todo funcionará bien. –

+1

Aparte ("los hace sentir grandes"): siempre que no explico algo porque la explicación es demasiado compleja, me siento más pequeño, no más grande. – phoog

Respuesta

9

que explicar el concepto a los laicos usando una analogía que la mayoría de la gente a entender - moldeo de plástico.

La interfaz define la forma de un objeto de la misma manera exacta un molde proporcionará la forma del producto acabado.

Se puede inyectar un molde con plástico blanco, de plástico azul, algo exótico como un epoxi o arcilla.

Lo que importa es, no importa lo que realmente están hechas de, todos ellos tienen la misma forma consistente exacta para el comprador del producto.

Para el código, esto significa que no importa qué código se utiliza para implementar la interfaz, todos siguen el mismo contrato/forma coherente para el usuario final.

Espero que pueda ayudar un poco.

Editar -

Para extender la analogía con clases abstractas, imaginemos el siguiente paso en el proceso de moldeo. Ejecutas una producción de plástico blanco, azul y rojo, pero luego cada artículo debe ser pintado en una fábrica separada, solo los enviamos.

El elemento no está terminado, pero tiene su forma definida. Alguien más tarde vendrá y completará los detalles que nuestra fábrica dejó en blanco.

Estos artículos no se pueden vender hasta que obtengan el último paso de pintado.

En el código, la implementación abstracta de la interfaz proporciona algunos (o ninguno) de la implementación, pero deja otra clase descendiente para completar el contrato, y de la misma manera nadie puede crear una instancia de la clase hasta el contrato se ha completado.

Del mismo modo, igual puede referirse a una clase abstracta en el código, al igual que puede referirse al artículo de molde sin pintar como una "cosa de moldeado blanco" o no pintada.

Editar 2

Aquí está un ejemplo corto

void Main() 
{ 
    //IMold mold = new IMold(); // error - can't create instance of an interface 
    //Fruit fruit = new Fruit(); // error - can't create instance of an abstract class 

    Apple apple1 = new Apple(); // good 
    Orange orange1 = new Orange(); // good 

    Fruit apple2 = (Fruit)apple1; // good - Apples are fruit 
    Fruit orange2 = (Fruit)orange1; // good - oranges are fruit 

    IFruitMold apple3 = (IFruitMold)apple2; // good - Apples fit the Mold 
    IFruitMold orange3 = (IFruitMold)orange2; // good - Oranges also fit the mold 


    //now I can do this: 
    //Notice that `fruits` is of type IList<T> but the new is List<T> 
    //This is the exact concept we are talking about 
    //IList<T> is some kind of set of items that can be added or subtracted from 
    //but we don't have to care about the implementation details of *HOW* this is done 
    IList<IFruitMold> fruits = new List<IFruitMold>(); 
    fruits.add(apple3); 
    fruits.add(orange3); 

    foreach(var fruit in fruits) 
    { 
     fruit.PlasticColor.Dump(); // ok I can read 
     fruit.PlasticColor = ""; // error - no Set defined in the interface 

     // depending on the **implementation details** of what type of fruit this is true or false 
     // we don't care in the slightest, we just care that we have some IFruitMold instances 
     fruit.RequiresPainting.Dump(); 
    } 
} 

interface IFruitMold 
{ 
    string PlasticColor { get; } 
    bool RequiresPainting { get; } 
} 

abstract class Fruit : IFruitMold 
{ 
    private string m_PlasticColor = string.Empty; 
    public string PlasticColor { get; private set; } 
    public abstract bool RequiresPainting { get; } 
} 

//notice that we only define the abstract portion of the base class 
//it defined PlasticColor for us already! 
//the keyword `override` is required - it is to make it clear that 
//this member is overriding a member from it's parent. 
class Apple : Fruit 
{ 
    public override bool RequiresPainting { get { return true; } } 
} 

class Orange : Fruit 
{ 
    public override bool RequiresPainting { get { return false; } } 
} 
+0

en realidad ayuda. así que, básicamente, estás predefiniendo métodos (forma allí) pero no núcleo (el código contenido dentro). siempre que el código en el cuerpo del método implementado siga la impresión azul establecida para él (tipo de devolución, cantidad y tipo de argumentos, etc.), todo debería funcionar bien. – zero

+0

@codewombat Lo tienes. Tengo un proyecto que puede enviar datos a un servicio web externo, una base de datos mssql2008 o una base de datos iseries db2. Los detalles de cómo leer y escribir en estos sistemas son muy diferentes, pero debido a que tengo una interfaz de lectura/escritura simple que todos ellos implementan, el resto del proyecto solo solicita un proveedor de datos y llama a "Obtener" o "Actualizar" "y nunca tiene que preocuparse por los detalles. Esa es la verdadera clave de todo esto: está utilizando interfaces para ocultar detalles de implementación. – asawyer

+0

@codewombat Edité en otra analogía para cubrir implementaciones de interfaces abstractas. – asawyer

2

Sí, en pocas palabras, las interfaces están ahí para declarar y prometer a todos los demás que una clase tendrá ciertos métodos.

Esto es bueno cuando crea métodos y funciones generalizadas, donde desea un diseño más abstracto. Todo lo que desea saber es que su función puede recibir un objeto que tenía los métodos A B y C.

+1

Un ejemplo perfecto del uso de interfaces es MouseListener. http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/event/MouseListener.html –

+0

@Perry Monschau excelente enlace. Entonces, ¿en una interfaz tengo que usar todos los métodos en la interfaz o puedo elegir cuál definir? – zero

+1

Debe implementar todos los métodos de la interfaz, de lo contrario no cumple los requisitos de esa interfaz. Cuando adjuntas un objeto que implementa la interfaz 'MouseListener' a un botón, al botón no le importa qué es realmente el objeto. Sabe que puede llamar 'mouseClicked()', 'mouseEntered()', etc. al objeto, y eso es todo lo que importa. –

2

La interfaz es simplemente una clase vacía, que muestra el contrato sobre cómo debería verse la clase real. Creo que tienes el concepto bien.

No reservan nada (no entiendo lo que quieres decir con eso), es solo una manera, así que cuando construyes tu clase alrededor de la interfaz, tienes un conocimiento previo de cómo se verá tu clase. Y también puedes saber qué métodos tendrá.

+0

O, en Java y C#, para que pueda tener un "tipo", con comportamientos específicos, sin requerir que una clase extienda 'MySpiffyBaseClass'. Algunas cosas simplemente no deberían requerir perder la única ranura de la superclase. Auditores de eventos en Java, por ejemplo. – cHao

1

Las interfaces proporcionan una forma uniforme de interacción con un conjunto de objetos.

Independientemente de qué objeto sea, si implementa la interfaz, sabemos que responderá a un método definido en la interfaz. De esta manera, podemos crear objetos que representan cosas diferentes en un proyecto y aún interactuar con ellos de la misma manera. La implementación real de los métodos definidos en la interfaz puede ser completamente diferente, pero tomarán las mismas entradas y proporcionarán el mismo tipo de salida.

2

Cuando una clase implementa una interfaz (o interfaces) se ve forzado a definir el cuerpo de cada método desde la (s) interfaz (es).

Sí. Las interfaces son contratos. Permiten que otros sepan que su clase implementa cierta funcionalidad.

1

Básicamente, una interfaz es un contrato que puede definir propiedades (getters y setters) o métodos (con los parámetros que requiera). Si un objeto 'implementa' la interfaz, necesita definir una implementación concreta para TODAS las propiedades y métodos definidos en la interfaz.

Para pruebas unitarias o Inversores de control, las interfaces de contenedores realmente entran en acción, ya que puede llamar a métodos/propiedades en la interfaz sin saber nada sobre el objeto que realmente lo implementa.

10

Por alguna razón la gente le encanta usar explicaciones excesivamente complejas y jerga para explicar conceptos verdaderamente simples (supongo que les hace sentir grande)

Considerar dejando de lado los comentarios editoriales que imputan malos motivos a las personas que están tratando para ayudarte. Esa es una manera realmente mala de intentar que la gente te ayude.

Parece que las interfaces no son más que una manera de reservar los nombres de métodos, su tipo de retorno, si lo hay, y el tipo y número de argumentos que requieren. Entonces, cuando una clase implementa una interfaz (o interfaces), se ve forzado a definir el cuerpo de cada método desde la (s) interfaz (es). ¿Estoy en la nariz con este o necesito seguir cavando?

Está en el camino correcto pero se equivoca en los detalles. En C#, por ejemplo, una clase de implementación no es requiere para proporcionar un cuerpo. El método que corresponde al método de interfaz podría, por ejemplo, ser un método abstracto en una clase abstracta, que luego no tendría un cuerpo. Y en C#, una interfaz puede requerir miembros distintos a los métodos; propiedades, eventos e indexadores, por ejemplo.

Una manera más concisa y típico para expresar la idea que sirve de interfaz imponer un requisitoque un tipo suministro miembros que coincidan con ciertos firmas es decir que la interfaz representa un contrato que deben ser cumplido por su implementador. Pero eso podría ser demasiado complejo y jerárquico para que tu intestino tenga estómago.

+0

"Por alguna razón, a la gente le encanta usar explicaciones demasiado complejas y jerga para explicar conceptos verdaderamente simples (supongo que los hace sentir grandes)" lo que me dice es que al buscar en mares de libros encontré que las interfaces no están claramente explicadas tampoco hay un buen ejemplo de su uso cotidiano/del mundo real. – zero

+0

"Pero eso podría ser demasiado complejo y poco hábil para que tu intestino tenga estómago". está bien, creo que las respuestas que todos los demás dieron son perfectamente adecuadas para mis necesidades;) – zero

1

interfaz se utiliza para proporcionar una funcionalidad común entre un conjunto de objetos completamente no relacionados.

digamos que tenemos un montón de objetos y animales que necesitamos para separar las mascotas de ese grupo. La tarea de separación se vuelve realmente simple si hacemos cumplir un contrato de tal manera que todos los animales que son mascotas necesiten implementar la interfaz IPet.

2

Yo diría que es más de reservándose el nombre del método es una forma de hacer un contrato que va a existir el método y la persona que llama no necesita saber lo que hace, pero seguirá estando disponible para ser llamado

Un buen ejemplo sería un bolígrafo y un lápiz. Ambos pueden implementar una interfaz Iwriter con un método de escritura, pero quien llama al método de escritura no necesita saber que uno usa tinta y uno usa el cable; el llamador sabrá que lo hará. escribe palabras en el papel.

+0

, por lo tanto, al llamar a la interfaz solo necesitan saber qué argumentos se necesitan y qué tipo de datos devuelve y quedan para definir qué hace. – zero

+1

que es correcto. No necesitan preocuparse en absoluto de lo que está pasando una vez que se llama todo lo que se necesita es lo que entra y lo que está saliendo (si se devuelve algo) –

Cuestiones relacionadas