Was bedeutet es, "auf eine Schnittstelle zu programmieren"?

Question

Ich habe das schon ein paar Mal gehört und weiß nicht, was es bedeutet. Wann und warum sollten Sie dies tun?

Ich weiß, was Schnittstellen bewirken, aber die Tatsache, dass ich mir darüber nicht im Klaren bin, lässt mich glauben, dass ich sie nicht richtig nutze.

Ist es einfach so, wenn Sie das tun würden:

IInterface classRef = new ObjectWhatever()

Sie können jede Klasse verwenden, die IInterface ? Wann sollten Sie das tun? Das Einzige, was mir einfällt, ist, wenn Sie eine Methode haben und sich nicht sicher sind, welches Objekt außer der Implementierung der Methode übergeben werden soll. IInterface . Ich kann mir nicht vorstellen, wie oft Sie das tun müssen.

Und wie kann man eine Methode schreiben, die ein Objekt aufnimmt, das eine Schnittstelle implementiert? Ist das möglich?

Answer 1

Es gibt hier einige wunderbare Antworten auf diese Fragen, die in alle möglichen Details über Schnittstellen und lose Kopplung von Code, Umkehrung der Kontrolle und so weiter gehen. Es gibt einige ziemlich hitzige Diskussionen, daher möchte ich die Gelegenheit nutzen, die Dinge ein wenig herunterzubrechen, um zu verstehen, warum eine Schnittstelle nützlich ist.

Als ich zum ersten Mal mit Schnittstellen in Berührung kam, war auch ich verwirrt über ihre Bedeutung. Ich habe nicht verstanden, warum man sie braucht. Wenn wir eine Sprache wie Java oder C# verwenden, haben wir bereits Vererbung, und ich sah Schnittstellen als eine schwächer Form der Vererbung und dachte: "Wozu die Mühe?" In gewisser Weise hatte ich Recht, man kann Schnittstellen als eine Art schwache Form der Vererbung betrachten, aber darüber hinaus verstand ich schließlich ihren Nutzen als Sprachkonstrukt, indem ich sie als Mittel zur Klassifizierung gemeinsamer Merkmale oder Verhaltensweisen betrachtete, die von potenziell vielen nicht verwandten Objektklassen gezeigt wurden.

Ein Beispiel: Sie haben ein SIM-Spiel mit den folgenden Klassen:

class HouseFly inherits Insect {
    void FlyAroundYourHead(){}
    void LandOnThings(){}
}

class Telemarketer inherits Person {
    void CallDuringDinner(){}
    void ContinueTalkingWhenYouSayNo(){}
}

Es ist klar, dass diese beiden Objekte in Bezug auf die direkte Vererbung nichts gemeinsam haben. Aber man könnte sagen, sie sind beide lästig.

Nehmen wir an, unser Spiel benötigt eine Art von Zufallsgenerator. Sache das den Spieler beim Essen stört. Dies könnte ein HouseFly oder eine Telemarketer oder beides - aber wie kann man beides mit einer einzigen Funktion berücksichtigen? Und wie bittet man die verschiedenen Arten von Objekten, ihre "lästigen Aufgaben" auf dieselbe Weise zu erledigen?

Das Wichtigste ist, dass sowohl ein Telemarketer y HouseFly haben ein gemeinsames, frei interpretierbares Verhalten, auch wenn sie sich bei der Modellierung nicht ähneln. Lassen Sie uns also eine Schnittstelle schaffen, die beide implementieren können:

interface IPest {
    void BeAnnoying();
}

class HouseFly inherits Insect implements IPest {
    void FlyAroundYourHead(){}
    void LandOnThings(){}

    void BeAnnoying() {
        FlyAroundYourHead();
        LandOnThings();
    }
}

class Telemarketer inherits Person implements IPest {
    void CallDuringDinner(){}
    void ContinueTalkingWhenYouSayNo(){}

    void BeAnnoying() {
        CallDuringDinner();
        ContinueTalkingWhenYouSayNo();
    }
}

Wir haben jetzt zwei Klassen, die jede auf ihre eigene Weise nervig sein können. Und sie müssen nicht von der gleichen Basisklasse abgeleitet sein und gemeinsame inhärente Eigenschaften haben - sie müssen lediglich den Vertrag von IPest -- dieser Vertrag ist einfach. Sie müssen nur BeAnnoying . In diesem Zusammenhang können wir das Folgende modellieren:

class DiningRoom {

    DiningRoom(Person[] diningPeople, IPest[] pests) { ... }

    void ServeDinner() {
        when diningPeople are eating,

        foreach pest in pests
        pest.BeAnnoying();
    }
}

Hier haben wir einen Speisesaal, der eine Reihe von Gästen und eine Reihe von Schädlingen aufnimmt - beachten Sie die Verwendung der Schnittstelle. Das bedeutet, dass in unserer kleinen Welt, ein Mitglied der Gruppe pests Array könnte eigentlich ein Telemarketer Objekt oder ein HouseFly Objekt.

Le site ServeDinner Methode wird genannt, wenn das Abendessen serviert wird und unsere Leute im Speisesaal essen sollen. In unserem kleinen Spiel verrichten unsere Schädlinge ihre Arbeit - jeder Schädling wird angewiesen, durch den IPest Schnittstelle. Auf diese Weise können wir leicht sowohl Telemarketers y HouseFlys auf ihre eigene Art und Weise ärgerlich sein - uns interessiert nur, dass wir etwas in der DiningRoom Objekt, das ein Schädling ist, interessiert uns nicht wirklich, was es ist, und sie könnten nichts mit anderen gemeinsam haben.

Dieses sehr konstruierte Pseudocode-Beispiel (das sich viel länger hinzog, als ich erwartet hatte) soll einfach nur veranschaulichen, was mir endlich ein Licht aufgegangen ist, wenn es um die Verwendung einer Schnittstelle geht. Ich entschuldige mich im Voraus für die Albernheit des Beispiels, hoffe aber, dass es Ihnen hilft, es zu verstehen. Und natürlich decken die anderen Antworten, die Sie hier erhalten haben, die ganze Bandbreite der Verwendung von Schnittstellen in Entwurfsmustern und Entwicklungsmethoden ab.

Answer 2

Das konkrete Beispiel, das ich den Schülerinnen und Schülern gebe, ist, dass sie schreiben sollen

List myList = new ArrayList(); // programming to the List interface

anstelle von

ArrayList myList = new ArrayList(); // this is bad

In einem kurzen Programm sehen diese genau gleich aus, aber wenn Sie weitergehen und myList 100 Mal in Ihr Programm einfügen, werden Sie einen Unterschied feststellen können. Die erste Deklaration stellt sicher, dass Sie nur Methoden auf myList die durch die Definition der List Schnittstelle (also keine ArrayList spezifische Methoden). Wenn Sie auf diese Weise für die Schnittstelle programmiert haben, können Sie später entscheiden, dass Sie wirklich brauchen

List myList = new TreeList();

und Sie müssen Ihren Code nur an dieser einen Stelle ändern. Sie wissen bereits, dass der Rest Ihres Codes nichts tut, was durch die Änderung der Umsetzung denn Sie programmierten auf die Schnittstelle .

Die Vorteile sind sogar noch offensichtlicher (denke ich), wenn es um Methodenparameter und Rückgabewerte geht. Nehmen wir zum Beispiel dies:

public ArrayList doSomething(HashMap map);

Diese Methodendeklaration bindet Sie an zwei konkrete Implementierungen ( ArrayList y HashMap ). Sobald diese Methode von einem anderen Code aufgerufen wird, bedeutet jede Änderung dieser Typen wahrscheinlich, dass Sie auch den aufrufenden Code ändern müssen. Es wäre besser, für die Schnittstellen zu programmieren.

public List doSomething(Map map);

Jetzt spielt es keine Rolle mehr, welche Art von List Sie zurückkehren, oder welche Art von Map als Parameter übergeben wird. Änderungen, die Sie innerhalb der doSomething Methode werden Sie nicht gezwungen, den aufrufenden Code zu ändern.

Answer 3

Programmieren für eine Schnittstelle heißt: "Ich brauche diese Funktionalität und es ist mir egal, woher sie kommt."

Betrachten Sie (in Java) die List Schnittstelle gegenüber der ArrayList y LinkedList konkrete Klassen. Wenn mir nur wichtig ist, dass ich eine Datenstruktur mit mehreren Datenelementen habe, auf die ich durch Iteration zugreifen soll, würde ich eine List (und das ist in 99 % der Fälle der Fall). Wenn ich weiß, dass ich eine konstante Zeitspanne für das Einfügen/Löschen von einem der beiden Enden der Liste benötige, wähle ich vielleicht die LinkedList konkrete Umsetzung (oder, was wahrscheinlicher ist, die Warteschlange Schnittstelle). Wenn ich weiß, dass ich zufälligen Zugriff nach Index benötige, würde ich die ArrayList konkrete Klasse.

Answer 4

Die Programmierung für eine Schnittstelle hat absolut nichts mit abstrakten Schnittstellen zu tun, wie wir sie in Java oder .NET sehen. Es handelt sich nicht einmal um ein OOP-Konzept.

Das bedeutet, dass man sich nicht mit den Interna eines Objekts oder einer Datenstruktur herumschlagen sollte. Verwenden Sie die abstrakte Programmschnittstelle oder API, um mit Ihren Daten zu interagieren. In Java oder C# bedeutet das, dass Sie öffentliche Eigenschaften und Methoden anstelle des einfachen Feldzugriffs verwenden. In C bedeutet das die Verwendung von Funktionen anstelle von reinen Zeigern.

EDIT: Bei Datenbanken bedeutet dies, dass Ansichten und gespeicherte Prozeduren anstelle des direkten Tabellenzugriffs verwendet werden.

Answer 5

Die Verwendung von Schnittstellen ist ein Schlüsselfaktor, um Ihren Code leicht testbar zu machen und unnötige Kopplungen zwischen Ihren Klassen zu vermeiden. Indem Sie eine Schnittstelle erstellen, die die Operationen Ihrer Klasse definiert, geben Sie Klassen, die diese Funktionalität nutzen wollen, die Möglichkeit, sie zu verwenden, ohne direkt von Ihrer implementierenden Klasse abhängig zu sein. Wenn Sie später beschließen, eine andere Implementierung zu verwenden, brauchen Sie nur den Teil des Codes zu ändern, in dem die Implementierung instanziiert wird. Der Rest des Codes muss nicht geändert werden, da er von der Schnittstelle und nicht von der implementierenden Klasse abhängt.

Dies ist sehr nützlich bei der Erstellung von Unit-Tests. In der zu testenden Klasse lässt man sie von der Schnittstelle abhängen und injiziert eine Instanz der Schnittstelle in die Klasse (oder eine Fabrik, die es ihr ermöglicht, Instanzen der Schnittstelle nach Bedarf zu erstellen) über den Konstruktor oder einen Eigenschaftssetzer. Die Klasse verwendet die bereitgestellte (oder erstellte) Schnittstelle in ihren Methoden. Wenn Sie Ihre Tests schreiben, können Sie die Schnittstelle nachahmen oder fälschen und eine Schnittstelle bereitstellen, die mit den in Ihrem Einheitstest konfigurierten Daten antwortet. Dies ist möglich, weil die zu testende Klasse nur mit der Schnittstelle und nicht mit ihrer konkreten Implementierung arbeitet. Jede Klasse, die die Schnittstelle implementiert, einschließlich Ihrer Mock- oder Fake-Klasse, ist geeignet.

EDIT: Im Folgenden finden Sie einen Link zu einem Artikel, in dem Erich Gamma sein Zitat "Program to an interface, not an implementation" diskutiert.

http://www.artima.com/lejava/articles/designprinciples.html