"Programming against the interface" sinnvoll?

[TSH]

Was meint Ihr, ist es sinnvoll für jede Klasse erstmal ein Interface zu definieren, um dann dagegen zu programmieren? Falls man es später mal austauschen möchte?

Viele Leute finden das ja besonders elegant und man ist flexibel und kann die Klassen einfach austauschen. Was aber, wenn man eigentlich überhaupt nicht vor hat die Klassen auszutauschen (oder nur in wenigen Fällen evtl. später mal). Ist es aus pragmatischer Sicht dann nicht besser, gleich gegen die Klassen zu programmieren und die Interfaces weg zu lassen? Ist ja dann Mehraufwand und der Code wird unübersichtlicher.

Wie ist da Eure Meinung?

 

[byte]

Meine Meinung: Interface nur dann, wenn es Sinn macht.

 

[TSH]

Was meinst Du mit "Sinn"?

Dann, wenn man auch wirklich von vorne rein verschiedene Klassen hat, die dieses Interface implementieren?

 

[Wildcard]

Ein Interface ist besonders nützlich um die Schnittstelle zwischen Modulgrenzen zu beschreiben.
Generell, Programmierung hin zur Schnittstelle ja, ein eigenes Interface für jeden Mist nein.

 

[ice-breaker]

Im Grunde programmiert man nur gegen Schnittstellen und keine konkreten Implementierungen, denn auch wenn du nicht vor hast die Klasse irgendwann mal zu ändern, kann es vllt notwendig werden

 

[Wildcard]

Das 'nur' würde ich vorsichtig betrachten. Das würde nämlich bedeuten das du für jede Klasse ein Interface hast und das ist definitiv nicht Sinn der Sache. Die Kunst ist, die Grenzen richtig zu setzen.

 

[MQue]

Hallo,

gibts da ein Beispiel, wie das aussieh, wenn man gegen eine Schnittstelle programmiert,


Das heiß ja quasi, dass ich in die Schnittstelle alles gebe, was die Klassen, die diese Schnittstelle implementieren, benötigen, oder?

lg

 

[Rock Lobster]

Nein, nur all das, was von außen her benötigt wird. Also alle öffentlichen Methoden, sodaß nach außen hin klar ist, was aufgerufen werden können muß.

Daher ja auch der Name "Schnittstelle". Im Grunde ist das wie, wenn Du bei einem Gebäude die Ein- und Ausgänge definierst. Was innen passiert, geht einen Lieferanten z.B. nix an, aber er muß wissen, wo er sein Material anliefern kann usw.
EDIT: Und dieser "Bauplan" kann dann für mehrere verschiedene Gebäude verwendet werden. Innen drin unterscheiden sie sich dann zum Teil sehr stark, aber die Ein- und Ausgänge sind immer an der gleichen Stelle. Wenn der Lieferant dann sowohl zur Schreinerei als auch zur Metallwerkstatt Sachen liefern muß, dann weiß er gleich, wo er hin muß, weil die Gebäude von außen genau gleich aussehen und die Tore gleich angeordnet sind, und er weiß auch, daß sein LKW in beiden Fällen geeignet ist.

Das ist der Sinn einer Schnittstelle

 

[MQue]

Gibts da ein anschauliches Programmierbeispiel dafür?

 

[Rock Lobster]

Naja da gibt's etliche. Schau Dir doch einfach z.B. das "List"-Interface in Java an. Da ist ganz klar definiert, wie man Objekte zur Liste hinzufügen, wieder rausholen und löschen kann.

Aber es gibt einige unterschiedliche Implementierungen, z.B. die ArrayList, die LinkedList, und sicher noch ein paar mehr. Intern funktionieren sie unterschiedlich, d.h. die Art, wie sie Daten speichern und sortieren, ist anders. Aber die Benutzung ist immer gleich, d.h. Du verwendest immer genau dieselben Methoden um Objekte einzufügen oder rauszuholen. Manche haben vielleicht noch zusätzliche Methoden, aber das macht nix, die Grundfunktionalitäten aus dem Interface sind GARANTIERT.

Und wenn einer Dir nun an 'ne Funktion eine Liste übergeben will, und Du einfach nur eine "List" (also das Interface) erwartest, dann kann er selbst entscheiden, ob er Dir eine LinkedList oder eine ArrayList gibt, da es für Deine Funktion keinen Unterschied macht.

Andere Beispiele gibt's bestimmt zuhauf...

 

[WieselAc]

In java zum Beispiel das List, Map, Set interface.

Ob du nun bei List eine ArrayList oder LinkedList benutzt ist egal. Alle Listen müssen z.B. Sachen hinzufügen oder entfernen können. Wie der konkrete Implementung aussieht ist dann wurscht.

Und jenachdem was für deinen konkreten Anwendungsfall cleverer (effizienter) erscheint, das bnutzt du dann um deine List zu instanzieren.

 

[TSH]

Gibt's für die Paketnamen der Interfaces und Klassen eigentlich allgemein gültige Konventionen?

Kommen Interfaces und implementierende Klasse(n) üblicherweise ins gleiche Paket:

com.myapp.gui.window (Interface)
com.myapp.gui.blueWindow (Klasse)
com.myapp.gui.redWindow (Klasse)

Oder macht man zB

com.myapp.gui.* (Klassen) und
com.myapp.gui.interfaces.* (Interfaces)

oder

com.myapp.gui.impl.* (Klassen)und
com.myapp.gui.* (Interfaces)

 

[SlaterB]

halte dich da im Zweifel an die Java-Bilbilothek:

java.util.List
java.util.ArrayList

aber anderes ist natürlich auch denkbar,


schreibe vor allem Klassen und Interface groß, das ist viel wichtiger als vieles andere..

 

[TSH]

Also Klassen und Interfaces ins gleiche Paket? (Natürlich schreib ich die groß, war gerade nur ein Versehen)

 

[SlaterB]

tolle Nachfrage, ich beantworte die jetzt eingeschnappt nicht
lies dir noch mal mein Posting durch und überlege,
ob dessen Aussage
'Klassen und Interfaces ins gleiche Paket'
oder
'Klassen und Interfaces nicht ins gleiche Paket'
ist

Tipp: wenn ich ein Beispiel in meinem Posting hatte (ich kann mich schon kaum mehr erinnern)
dann war das bestimmt von der Sorte, die zu meiner intendierten Aussage passt

 

[TSH]

Hm, ich glaube, ich verstehe... ;-)

 

[Rock Lobster]

Bei uns in der Firma fangen Interface-Namen oft mit einem "I" an, also würde eine konkrete Klasse vielleicht "ColaDose" heißen, und ein passendes Interface dazu "IGetraenkeDose". Ist jetzt ein dummes Beispiel aber mir ist grad nix besseres eingefallen.

Ist halt Geschmacksache, aber sooo schlecht finde ich diese Lösung gar nicht. Manche schreiben vor Klassen auch immer ein "C", also wäre es dann eine "CColaDose" und eine "CFantaDose", aber das find ich häßlich und übertrieben. Interfaces hat man jedoch i.d.R. nicht so viele, und da kann es schon ganz sinnvoll sein, diese durch ein "I" zu kennzeichnen oder so. Ist aber letztendlich jedem selbst überlassen, wie er das in seinem Projekt handhaben möchte....

EDIT: Muß noch dazusagen, daß wir das eigentlich nur bei Interfaces machen, bei denen es nicht gerade offensichtlich ist. Bei einem Listener z.B. finde ich das I unnötig, da Listener meistens im Namen das Wort "Listener" haben und diese grundsätzlich Interfaces sind.

 

[byte]

Das finde ich nun die schlechteste Lösung. Entweder immer I als Prefix oder nie. Ich würds weglassen. Vernünftige IDEs bieten einem genug Möglichkeiten, die Dateien zu unterscheiden. Da braucht man nicht noch die Namen verschandeln.

 

[Rock Lobster]

Naja unter C++ ist das vielleicht sinnvoller, weil es dort eben kein "interface"-Keyword gibt. Könnte mir auch vorstellen, daß dieses I-Prefix noch aus dieser Zeit stammt. Klar, unter Java gibt's eh schon sprachlich die Unterscheidung, und die IDE kann dann einfach ein entsprechendes Icon anzeigen.