Cuál es la definición de “interfaz” en progtwigción orientada a objetos

Ok, un amigo mío va y viene en lo que significa “interfaz” en la progtwigción.

¿Cuál es la mejor descripción de una “interfaz”?

Para mí, una interfaz es un plano de una clase, ¿es esta la mejor definición?

Considera la siguiente situación:

Estás en el medio de una habitación grande y vacía, cuando un zombie te ataca de repente.

No tienes arma.

Afortunadamente, un compañero humano está de pie en la entrada de la habitación.

“¡Rápido!” le gritas a él. “¡Tírame algo con lo que pueda golpear al zombi!”

Ahora considera:
No especificó (ni le importa) exactamente lo que su amigo decidirá lanzar;
… Pero no importa, siempre y cuando:

  • Es algo que se puede lanzar (no puede tirarte el sofá)

  • Es algo que puedes agarrar (Esperemos que no haya arrojado un shuriken)

  • Es algo que puedes usar para golpear los cerebros del zombi (Eso descarta almohadas y cosas por el estilo)

No importa si obtienes un bate de béisbol o un martillo
siempre y cuando implemente tus tres condiciones, eres bueno.

En resumen:

Cuando escribes una interfaz, básicamente estás diciendo: “Necesito algo que …”

No creo que “blueprint” sea una buena palabra para usar. Un plano te dice cómo construir algo. Una interfaz evita específicamente decirle cómo construir algo.

Una interfaz define cómo puede interactuar con una clase, es decir, qué métodos admite.

Para mí, una interfaz es un plano de una clase, ¿es esta la mejor definición?

No. Un anteproyecto generalmente incluye las partes internas. Pero una interfaz es puramente sobre lo que es visible en el exterior de una clase … o más exactamente, una familia de clases que implementan la interfaz.

La interfaz consiste en firmas de métodos y valores de constantes, y también un (típicamente informal) “contrato de comportamiento” entre clases que implementan la interfaz y otras que la usan.

Técnicamente, describiría una interfaz como un conjunto de formas (métodos, propiedades, accesadores … el vocabulario depende del idioma que esté utilizando) para interactuar con un objeto. Si un objeto admite / implementa una interfaz, puede usar todas las formas especificadas en la interfaz para interactuar con este objeto.

Semánticamente, una interfaz también puede contener convenciones sobre lo que puede o no hacer (por ejemplo, el orden en que puede llamar a los métodos) y sobre lo que, a cambio, puede asumir sobre el estado del objeto dado cómo interactuó de modo lejos.

En Progtwigción, una interfaz define qué comportamiento tendrá un objeto, pero en realidad no especificará el comportamiento. Es un contrato, que garantizará, que cierta clase puede hacer algo.

Considera esta parte del código C # aquí:

using System; public interface IGenerate { int Generate(); } // Dependencies public class KnownNumber : IGenerate { public int Generate() { return 5; } } public class SecretNumber : IGenerate { public int Generate() { return new Random().Next(0, 10); } } // What you care about class Game { public Game(IGenerate generator) { Console.WriteLine(generator.Generate()) } } new Game(new SecretNumber()); new Game(new KnownNumber()); 

La clase Game requiere un número secreto. Para probarlo, le gustaría inyectar lo que se usará como un número secreto (este principio se llama Inversion of Control).

La clase de juego quiere ser “de mente abierta” sobre lo que realmente creará el número aleatorio, por lo tanto pedirá en su constructor “cualquier cosa, que tenga un método Generate”.

Primero, la interfaz especifica qué operaciones proporcionará un objeto. Simplemente contiene lo que parece, pero no se proporciona una implementación real. Esta es solo la firma del método. Convencionalmente, en las interfaces C # se agrega un prefijo I. Las clases ahora implementan la interfaz IGenerate. Esto significa que el comstackdor se asegurará de que ambos tengan un método que devuelva un int y se llame Generate . El juego ahora se llama dos objetos diferentes, cada uno de los cuales implementa la interfaz correcta. Otras clases producirían un error al construir el código.

Aquí noté la analogía del plan que usaste:

Una clase se ve comúnmente como un modelo para un objeto. Una interfaz especifica algo que una clase debe hacer, por lo que se podría argumentar que, de hecho, es solo un modelo para una clase, pero dado que una clase no necesita necesariamente una interfaz, diría que esta metáfora se está rompiendo. Piensa en una interfaz como un contrato. La clase que lo “firme” será legalmente requerida (exigida por la policía del comstackdor) para cumplir con los términos y condiciones del contrato. Esto significa que tendrá que hacer, lo que se especifica en la interfaz.

Todo esto se debe a la naturaleza estáticamente tipada de algunos lenguajes OO, como es el caso de Java o C #. En Python, por otro lado, se usa otro mecanismo:

 import random # Dependencies class KnownNumber(object): def generate(self): return 5 class SecretNumber(object): def generate(self): return random.randint(0,10) # What you care about class SecretGame(object): def __init__(self, number_generator): number = number_generator.generate() print number 

Aquí, ninguna de las clases implementa una interfaz. A Python no le importa eso, porque la clase SecretGame solo intentará llamar a cualquier objeto que se pase. Si el objeto TIENE un método generate (), todo está bien. Si no es así: ¡KAPUTT! Este error no se verá en tiempo de comstackción, pero en tiempo de ejecución, por lo tanto, posiblemente cuando su progtwig ya esté implementado y en ejecución. C # te avisaría mucho antes de que te acercaras a eso.

La razón por la cual se usa este mecanismo, se dice ingenuamente, porque en los lenguajes OO, naturalmente, las funciones no son ciudadanos de primera clase. Como puede ver, KnownNumber y SecretNumber contienen SÓLO las funciones para generar un número. Uno realmente no necesita las clases en absoluto. En Python, por lo tanto, uno podría descartarlos y elegir las funciones por sí mismos:

 # OO Approach SecretGame(SecretNumber()) SecretGame(KnownNumber()) # Functional Approach # Dependencies class SecretGame(object): def __init__(self, generate): number = generate() print number SecretGame(lambda: random.randint(0,10)) SecretGame(lambda: 5) 

Una lambda es solo una función, que fue declarada “en línea, sobre la marcha”. Un delegado es lo mismo en C #:

 class Game { public Game(Func generate) { Console.WriteLine(generate()) } } new Game(() => 5); new Game(() => new Random().Next(0, 10)); 

Los últimos ejemplos no son posibles así en Java, ya que Java no puede moverse con funciones como las otras dos (Python y C #). Allí, las interfaces son su única forma de comportamiento específico de esta manera en av.

Personalmente, veo una interfaz como una plantilla. Si una interfaz contiene la definición de los métodos foo () y bar (), entonces sabrá que cada clase que utiliza esta interfaz tiene los métodos foo () y bar ().

Consideremos un Hombre (Usuario u Objeto) que quiere que se haga algún trabajo. Se pondrá en contacto con un intermediario (Interfaz) que tendrá un contrato con las empresas (objetos del mundo real creados utilizando clases implementadas). Pocos tipos de trabajos serán definidos por él que las compañías implementarán y le darán resultados. Todas y cada una de las compañías implementarán el trabajo a su manera, pero el resultado será el mismo. De esta manera, el usuario realizará su trabajo utilizando una única interfaz. Creo que Interface actuará como parte visible de los sistemas con pocos comandos que serán definidos internamente por los subsistemas internos de implementación.

Una interfaz separa las operaciones en una clase de la implementación dentro de. Por lo tanto, algunas implementaciones pueden proporcionar muchas interfaces.

La gente generalmente lo describiría como un “contrato” de lo que debe estar disponible en los métodos de la clase.

No es absolutamente un plan, ya que eso también determinaría la implementación. Se podría decir que una definición de clase completa es un modelo.

Una interfaz define qué debe implementar una clase que hereda de ella. De esta forma, múltiples clases pueden heredar de una interfaz, y debido a eso, se puede

  • asegúrese de que todos los miembros de la interfaz estén implementados en la clase derivada (incluso si es solo para lanzar una excepción)
  • Resum la clase misma de la persona que llama (envíe una instancia de una clase a la interfaz e interactúe con ella sin necesidad de saber cuál es la clase derivada real)

para obtener más información, consulte este http://msdn.microsoft.com/en-us/library/ms173156.aspx

En mi opinión, la interfaz tiene un significado más amplio que el comúnmente asociado en Java. Definiría “interfaz” como un conjunto de operaciones disponibles con algunas funcionalidades comunes, que permiten controlar / monitorear un módulo.

En esta definición trato de cubrir tanto las interfaces programáticas, donde el cliente es algún módulo, como las interfaces humanas (GUI, por ejemplo).

Como ya se dijo, una interfaz siempre tiene algún contrato detrás, en términos de entradas y salidas. La interfaz no promete nada sobre el “cómo” de las operaciones; solo garantiza algunas propiedades del resultado, dado el estado actual, la operación seleccionada y sus parámetros.

Como se indicó anteriormente, los sinónimos de “contrato” y “protocolo” son apropiados.

La interfaz comprende los métodos y propiedades que puede esperar que una clase exponga.

Entonces, si una clase Cheetos Bag implementa la interfaz Chip Bag , deberías esperar que una Cheetos Bag comporte exactamente como cualquier otra Chip Bag . (Es decir, exponer el método .attemptToOpenWithoutSpillingEverywhere() , etc.)

la interfaz es “qué trabajo” un método no “cómo”. Es un contrato. Como en la cola de prioridad, sabes qué hacer con ella, pero la implementación subyacente no la conoces. La clase acepta nunca cambiar los “efectos” de las operaciones existentes, y el cliente acepta usar la clase estrictamente sobre la base de su interfaz e ignorar cualquier detalle de implementación.

Layman, por ejemplo: piense en tener un control remoto universal que pueda controlar cualquier televisor, ya sea un modelo de tubo antiguo o uno que use una pantalla LCD o de plasma. Presiona 2, luego 5, luego Intro, y cualquiera de las pantallas mostrará el canal 25, aunque el mecanismo para hacerlo es muy diferente dependiendo de la tecnología subyacente.

Un límite a través del cual se comunican dos sistemas.

Las interfaces son la forma en que algunos lenguajes OO logran polymorphism ad hoc . El polymorphism ad hoc simplemente funciona con los mismos nombres que operan en diferentes tipos.

Definición convencional: una interfaz es un contrato que especifica los métodos que necesita implementar la clase que lo implementa.

La definición de interfaz ha cambiado con el tiempo. ¿Crees que Interface solo tiene declaraciones de métodos? ¿Qué pasa con las variables finales estáticas y las definiciones predeterminadas después de Java 5?

Las interfaces se introdujeron en Java debido al problema Diamante con Herencia múltiple y eso es lo que realmente intentan hacer.

Las interfaces son las construcciones que se crearon para salirse con la suya con el problema de la herencia múltiple y pueden tener métodos abstractos, definiciones predeterminadas y variables finales estáticas.

http://www.quora.com/Why-does-Java-allow-static-final-variables-in-interfaces-when-they-are-only-intented-to-be-contracts