In der Programmierung definiert eine Schnittstelle das Verhalten eines Objekts, gibt das Verhalten jedoch nicht an. Es ist ein Vertrag, der garantiert, dass eine bestimmte Klasse etwas tun kann.
Betrachten Sie diesen Teil des C # -Codes hier:
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());
Die Spielklasse benötigt eine Geheimnummer. Zum Testen möchten Sie die als Geheimnummer verwendete Nummer injizieren (dieses Prinzip wird als Inversion of Control bezeichnet).
Die Spielklasse möchte "aufgeschlossen" sein, was die Zufallszahl tatsächlich erzeugt, und fragt daher in ihrem Konstruktor nach "allem, was eine Generierungsmethode hat".
Zunächst gibt die Schnittstelle an, welche Operationen ein Objekt bereitstellen wird. Es enthält nur, wie es aussieht, aber es wird keine tatsächliche Implementierung angegeben. Dies ist nur die Signatur der Methode. Herkömmlicherweise wird in C # -Schnittstellen ein I vorangestellt. Die Klassen implementieren jetzt die IGenerate-Schnittstelle. Dies bedeutet, dass der Compiler sicherstellt, dass beide eine Methode haben, die ein int zurückgibt und aufgerufen wirdGenerate . Das Spiel heißt jetzt zwei verschiedene Objekte, von denen jedes die richtige Schnittstelle implementiert. Andere Klassen würden beim Erstellen des Codes einen Fehler erzeugen.
Hier ist mir die von Ihnen verwendete Blaupausenanalogie aufgefallen:
Eine Klasse wird üblicherweise als Blaupause für ein Objekt angesehen. Eine Schnittstelle gibt etwas an, das eine Klasse tun muss, sodass man argumentieren könnte, dass es sich tatsächlich nur um eine Blaupause für eine Klasse handelt. Da eine Klasse jedoch nicht unbedingt eine Schnittstelle benötigt, würde ich argumentieren, dass diese Metapher nicht funktioniert. Stellen Sie sich eine Schnittstelle als Vertrag vor. Die Klasse, die es "unterschreibt", ist gesetzlich verpflichtet (von der Compiler-Polizei durchgesetzt), die Vertragsbedingungen einzuhalten. Dies bedeutet, dass es tun muss, was in der Schnittstelle angegeben ist.
Dies alles ist auf die statische Typisierung einiger OO-Sprachen zurückzuführen, wie dies bei Java oder C # der Fall ist. In Python wird dagegen ein anderer Mechanismus verwendet:
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
Hier implementiert keine der Klassen eine Schnittstelle. Python kümmert sich nicht darum, da die SecretGameKlasse nur versucht, das übergebene Objekt aufzurufen. Wenn das Objekt eine generate () -Methode hat, ist alles in Ordnung. Wenn nicht: KAPUTT! Dieser Fehler wird nicht zur Kompilierungszeit, sondern zur Laufzeit angezeigt, möglicherweise wenn Ihr Programm bereits bereitgestellt ist und ausgeführt wird. C # würde Sie benachrichtigen, bevor Sie dem nahe kommen.
Der Grund, warum dieser Mechanismus verwendet wird, ist naiv ausgedrückt, weil in OO-Sprachen Funktionen natürlich keine erstklassigen Bürger sind. Wie Sie sehen können KnownNumberund SecretNumbernur die Funktionen enthalten, um eine Zahl zu generieren. Den Unterricht braucht man eigentlich gar nicht. In Python könnte man sie daher einfach wegwerfen und die Funktionen selbst auswählen:
# 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)
Ein Lambda ist nur eine Funktion, die als "in line, as you go" deklariert wurde. Ein Delegat ist in C # genauso:
class Game
{
public Game(Func<int> generate)
{
Console.WriteLine(generate())
}
}
new Game(() => 5);
new Game(() => new Random().Next(0, 10));
Randnotiz: Die letzteren Beispiele waren bis Java 7 nicht so möglich. Dort waren Schnittstellen Ihre einzige Möglichkeit, dieses Verhalten zu spezifizieren. In Java 8 wurden jedoch Lambda-Ausdrücke eingeführt, sodass das C # -Beispiel sehr einfach in Java konvertiert werden kann ( Func<int>wird java.util.function.IntSupplierund =>wird ->).