¿Cuál es la definición de "interfaz" en la programación orientada a objetos?

Ok, un amigo mío va y viene sobre lo que significa "interfaz" en programació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?

Una interfaz es uno de los términos más sobrecargados y confusos en el desarrollo.

En realidad, es un concepto de abstracción y encapsulación. Para una "caja" dada, declara las "entradas" y "salidas" de esa caja. En el mundo del software, eso generalmente significa las operaciones que se pueden invocar en el cuadro (junto con los argumentos) y, en algunos casos, los tipos de retorno de estas operaciones.

Lo que no hace es definir cuál es la semántica de estas operaciones, aunque es un lugar común (y una muy buena práctica) documentarlas cerca de la declaración (por ejemplo, a través de comentarios), o elegir buenas convenciones de nomenclatura. Sin embargo, no hay garantías de que se sigan estas intenciones.

Aquí hay una analogía: mire su televisor cuando esté apagado. Su interfaz son los botones que tiene, los distintos enchufes y la pantalla. Su semántica y comportamiento es que toma entradas (por ejemplo, programación de cable) y tiene salidas (visualización en pantalla, sonido, etc.). Sin embargo, cuando mira un televisor que no está conectado, está proyectando la semántica esperada en una interfaz. Por lo que sabes, el televisor podría explotar cuando lo conectes. Sin embargo, según su "interfaz", puedes asumir que no hará café ya que no tiene una toma de agua.

En la programación orientada a objetos, una interfaz generalmente define el conjunto de métodos (o mensajes) a los que una instancia de una clase que tiene esa interfaz podría responder.

Lo que se suma a la confusión es que en algunos lenguajes, como Java, existe una interfaz real con su semántica específica del lenguaje. En Java, por ejemplo, es un conjunto de declaraciones de métodos, sin implementación, pero una interfaz también corresponde a un tipo y obedece a varias reglas de escritura.

En otros lenguajes, como C ++, no tiene interfaces. Una clase en sí misma define métodos, pero podría pensar en la interfaz de la clase como las declaraciones de los métodos no privados. Debido a cómo se compila C ++, obtienes archivos de encabezado donde podrías tener la "interfaz" de la clase sin una implementación real. También puede imitar interfaces Java con clases abstractas con funciones virtuales puras, etc.

Ciertamente, una interfaz no es un modelo para una clase. Un anteproyecto, según una definición, es un "plan de acción detallado". ¡Una interfaz no promete nada sobre una acción! La fuente de la confusión es que en la mayoría de los lenguajes, si tiene un tipo de interfaz que define un conjunto de métodos, la clase que lo implementa "repite" los mismos métodos (pero proporciona una definición), por lo que la interfaz parece un esqueleto o un esquema de la clase.

Considere la siguiente situación:

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

No tienes arma.

Afortunadamente, un compañero humano vivo está parado en la puerta de la habitación.

"¡Rápido!" le gritas. "¡Tírame algo con lo que pueda golpear al zombi!"

Ahora considere:
No especificó (ni le importa) exactamente lo que su amigo decidirá lanzar;
... Pero no importa, siempre que:

• Es algo que se puede tirar (no te puede tirar el sofá)

• Es algo a lo que puedes agarrarte (Esperemos que no haya lanzado un shuriken)

• Es algo que puedes usar para golpear los sesos del zombi (eso descarta almohadas y cosas así)

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

Para resumirlo:

Cuando escribes una interfaz, básicamente estás diciendo: "Necesito algo que ..."

La interfaz es un contrato que debe cumplir o ceder, dependiendo de si es un implementador o un usuario.

No creo que "blueprint" sea una buena palabra. 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 plano generalmente incluye los componentes internos. Pero una interfaz se trata puramente de lo que es visible en el exterior de una clase ... o más exactamente, una familia de clases que implementan la interfaz.

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

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

Considere este fragmento de 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 Juego requiere un número secreto. Para probarlo, le gustaría inyectar lo que se usará como un número secreto (este principio se llama Inversión de control).

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

Primero, la interfaz especifica qué operaciones proporcionará un objeto. Solo contiene lo que parece, pero no se proporciona una implementación real. Esta es solo la firma del método. Convencionalmente, en C # las interfaces tienen el prefijo I. Las clases ahora implementan la interfaz IGenerate. Esto significa que el compilador se asegurará de que ambos tengan un método que devuelva un int y sea llamado 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 plano que usaste:

Una clase se ve comúnmente como el modelo de un objeto. Una interfaz especifica algo que una clase necesitará hacer, por lo que se podría argumentar que de hecho es solo un modelo para una clase, pero dado que una clase no necesariamente necesita una interfaz, yo diría que esta metáfora se está rompiendo. Piense en una interfaz como un contrato. La clase que "lo firma" será legalmente requerida (ejecutada por la policía compiladora), 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 tipada estática 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 SecretGameclase solo intentará llamar a cualquier objeto que se le pase. Si el objeto TIENE un método generate (), todo está bien. Si no es así: ¡KAPUTT! Este error no se verá en el momento de la compilación, sino en el tiempo de ejecución, por lo que posiblemente cuando su programa ya esté implementado y en ejecución. C # le notificaría mucho antes de que se acercara a eso.

La razón por la que se utiliza este mecanismo es, ingenuamente, porque en los lenguajes OO las funciones no son, naturalmente, ciudadanos de primera clase. Como se puede ver, KnownNumbery SecretNumbersólo contienen las funciones para generar un número. Uno realmente no necesita las clases en absoluto. En Python, por lo tanto, uno podría simplemente tirarlos y elegir las funciones por su cuenta:

# 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 se declaró "en línea, sobre la marcha". Un delegado es igual en C #:

class Game
{
    public Game(Func<int> generate) 
    {
        Console.WriteLine(generate())
    }
}    

new Game(() => 5);
new Game(() => new Random().Next(0, 10));

Nota al margen: los últimos ejemplos no eran posibles así hasta Java 7. Allí, las interfaces eran su única forma de especificar este comportamiento. Sin embargo, Java 8 introdujo expresiones lambda para que el ejemplo de C # se pueda convertir a Java muy fácilmente (se Func<int>convierte en java.util.function.IntSuppliery se =>convierte ->).

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

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

Personalmente veo una interfaz como una plantilla. Si una interfaz contiene la definición de los métodos foo () y bar (), entonces sabrá que todas las clases que usan esta interfaz tienen los métodos foo () y bar ().

Consideremos que un Hombre (Usuario u Objeto) 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 mediante clases implementadas). Pocos tipos de trabajos serán definidos por él qué empresas implementarán y le darán resultados. Todas y cada una de las empresas implementarán el trabajo a su manera, pero el resultado será el mismo. Como este, el usuario hará 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. Por tanto, algunas implementaciones pueden proporcionar muchas interfaces.

La gente normalmente lo describiría como un "contrato" por lo que debe estar disponible en los métodos de la clase.

No es en absoluto 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 lo que debe implementar una clase que hereda de ella. De esta forma, varias clases pueden heredar de una interfaz y, debido a esa inherencia, 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)
• Extraiga la clase en sí 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 que comúnmente se le asocia en Java. Definiría "interfaz" como un conjunto de operaciones disponibles con alguna funcionalidad común, 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 han dicho otros, 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 antes, los sinónimos de "contrato" y "protocolo" son apropiados.

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

Entonces, si una clase Cheetos Bagimplementa la Chip Baginterfaz, debe esperar Cheetos Bagque se comporte exactamente como cualquier otra Chip Bag. (Es decir, exponer el .attemptToOpenWithoutSpillingEverywhere()método, etc.)

Definición convencional: una interfaz es un contrato que especifica los métodos que debe 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 de Diamond con la herencia múltiple y eso es lo que realmente pretenden 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-intended-to-be-contracts

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

Las interfaces son la forma en que algunos lenguajes OO logran un polimorfismo ad hoc . El polimorfismo ad hoc es simplemente funciones con los mismos nombres que operan en diferentes tipos.

En resumen, el problema básico que una interfaz está tratando de resolver es separar cómo usamos algo de cómo se implementa. Pero debe considerar que la interfaz no es un contrato . Leer más aquí .