Interfaces "Schreibaufwand"

[knowledge]

Zusammenfassend kann man also sagen ohne Interfaces keine statische Typisierung?

 

[Spacerat]

Uhh... neee... Es gibt noch andere Dinge die das gewährleisten (Abstrakte Klassen, enums... noch welche?). Interfaces ersetzen in Java die fehleranfällige Mehrfachveerbung (in Java nicht möglich), wie man sie z.B. in C++ kennt.

 

[slawaweis]

>welchem Interface entspricht fight() in Bauer? Ist A, oder B, oder C, oder doch D?
>
>Slawa

OK, das sehe ich ein. Aber zumindest bei Methoden aus der Java API könnte man doch drauf verzichten, oder nicht. Beispielsweise actionPerformed(). In diesem Fall müsste man doch verbieten können, das ein Benutzer seine Methoden nicht nach Methoden nennen darf, die in der Java API schon definiert sind. Wenn ich also actionPerformed irgendwo implementiere, dann könnte immer davon ausgegangen werden, dass es sich um einnen Listener handelt. Damit wäre eindeutigkeit hergestellt.

um das zu erklären, müssen wir in die Zeit der Dinosaurier zurückreisen. Vor langer langer Zeit gab es nur Assembler mit direkten Maschinenbefehlen, bis jemand auf die Idee kam abstrakte Namen für bestimmte Teilprogramme zu verwenden. So entstanden die imperativen Programmiersprachen. Darin gibt es keine Kapselung, jede Funktion ist global. So wäre ein actionPerformed() wirklich nur einmal definiert und jede weitere Definition würde es entweder überschreiben oder einen Compilerfehler auslösen. Nun wurden damals Programme mit Millionen von Quelltextzeilen geschrieben, von Tausenden von Programmierern, rund um den Globus. Wenn bei einem größeren Projekt mehrere Programmier auf die Idee kamen, in ihrem Teilprojekt eine Funktion gleich zu benennen, gab es später Probleme, wenn diese Teilprojekte zusammengefügt wurden. Kurz gesagt, es entstand ein Haufen Fehler alleine aus der Struktur des Codes und ein sehr großer Verwaltungsaufwand. Software, die über mehrere Generationen entwickelt wurde, glänzte dann mit solchen Sachen:

function() // Version 1
_function() // Version 2
__function() // Version 3.5
___function() // Version 4.28
____function() // Version 5.99

Kluge Köpfe der damaligen Zeit brüteten über Möglichkeiten das zu vereinfachen und sicherer zu machen. Aus diesen und anderen Problemen entstanden dann die objektorientierten Programmiersprachen, die extra dafür ausgelegt sind, bestimmte Funktionalität und Bezeichnung zu kapseln. Damit konnte man die Programme besser strukturieren. In ungefähr der Zeit entstand auch Java, d.h. man versuche die damaligen aktuellen Probleme und Lösungen brauchbar anzuwenden. So ist eine wichtige Eigenschaft von Java, dass Namen nur in einem Teilbereich eine Rolle spielen und nicht global.

Würde man jetzt Funktionen wie "actionPerformed()" wieder global machen, also dass keiner mehr seine Funktionen so nennen kann, dann wäre es quasi, als ob man eine Zeitmaschine baut und in die Zeit der Dinosaurier zurückreist, um die ganze Entwicklung wieder von vorne durchzumachen. Wobei actionPerformed() auffällig genug ist, aber sehen wir uns noch ein paar andere API-Funktionen an:

java.lang.Appendable.append()
java.lang.Readable.read()
java.lang.Runnable.run()
java.io.Closeable.close()
java.util.Observer.update()
java.util.Formattable.formatTo()

das ist nur eine kleine Auswahl, aber alle diese Namen, die in den öffentlichen API Interfaces definiert sind, wären für die Programmier quasi blockiert. Weiterhin wiederholen sich die gleichen Namen sogar in der API. Hinzu kommt das Problem, dass wenn in einer neuen Java Version ein neues Interface mit irgend einem neuen, aber einfachen Namen wie "String getName()", hinzukommt, dann wären plötzlich Hunderte von Programmen nicht mehr kompilierbar, weil diese mit dem neuen Interface kollidieren. Das selbe Problem hat Java mit Schlüsselwörtern. Man kann z.B. kein Schlüsselwort "foreach" mehr in die Sprache einführen, weil es bestimmt schon Tausende von Programmierern in ihren Programmen verwendet haben, entweder als Funktionsaufruf oder als Variablennamen. Weiterhin, was ist das API? Alles mit java.* und javax.*?

Interfaces zu implementieren ist keine Qual, sondern etwas sehr nützliches. Wenn man erst mal Programme mit Hunderttausenden von Zeilen und einem über mehrere Orte verteilten Programmiererteam entwickelt, sieht man die Sache schon ganz anders.

Slawa

 

[knowledge]

Ich hab mir nochmal meine Gedanken gemacht. Ich denke mal ein nicht zu unterschätzender Vorteil ist wirklich dass ich bei "fremden" Klassen oder später auf einen Blick sehe welches Interface implementiert wird und damit (bei guter Dokumentation) auf die Fähigkeiten der Klasse schliessen kann. Sonst müsste ich mir die gesamte Klasse anschauen und wissen welche Menge von Methoden zu welchem Interface gehört bzw. welche Gesamtfunktionalität die Klasse bieten soll.

Desweiteren wird dadurch sichergestellt, dass ich keine Methode vergesse die implementiert werden soll. Angenommen es ändert sich das Interface, dann merk ich das sofort, welche Klassen davon abhängig sind und wo dann die entsprechende Methode auch implementiert werden muss.