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 ->).