Discussion:
Grundsätzliche Frage zu Interfaces
(zu alt für eine Antwort)
Ralf S. Hellersen
2015-12-30 12:12:35 UTC
Permalink
Hallo zusammen,

nach der Suche von mehreren Erklärungen habe ich als Wiedereinsteiger in
Java immer noch eine Verständnisfrage zu Interfaces:
Welchen Vorteil bieten diese ?

Soweit ich verstanden habe:
Sie erhalten eine (abstrakte) Methode ohne dazugehörigen Kode, den ich
in der main-Klasse selber schreiben muss. Das bezeichne ich nicht als
Arbeitserleichterung. Ich verwende auch nicht wieder, was ein Vorteil
der objektorientierten Programmierung ist.

Hat jemand eine Antwort für mich ?

Gruß
Ralf
Stefan Ram
2015-12-30 12:49:05 UTC
Permalink
Post by Ralf S. Hellersen
Welchen Vorteil bieten diese ?
In Java erlauben Schnittstellen die statisch-typsichere
Verwendung von Polymorphie und von Patterns wie »Strategy«.

Eine Schnittstelle erlaubt es auch, einen abstrakten
Datentyp unabhängig von einer Implementation zu
dokumentieren und diese Dokumentation zu vererben.
Umgekehrt kann man Klassen leichter erlernen, wenn man
darin wiederkehrende Schnittstellen erkennen kann.

Schnittstellen als Parametertypen erlauben die Formulierung
abstrakter »Algorithmen auf Schnittstellen«, die dann erst durch
einen Aufruf an konkrete Typen gebunden werden können.
Etwas ganz Ähnliches gilt auch für Schnittstellen als Typen
lokaler Variablen, welche die Umstellung der verwendeten
konkreten Klassen erleichtern. (Aber dies sind nur Spezialfälle
der schon eingangs erwähnten Polymorphie.)

Man könnte dafür zwar auch manchmal Oberklassen verwenden,
aber Schnittstellen erlauben in Java auch mehrfache Beererbung,
welche in diesem Zusammenhang auch oft benötigt und verwendet wird.
Jan Burse
2015-12-30 14:54:19 UTC
Permalink
Post by Stefan Ram
Man könnte dafür zwar auch manchmal Oberklassen verwenden,
aber Schnittstellen erlauben in Java auch mehrfache Beererbung,
welche in diesem Zusammenhang auch oft benötigt und verwendet wird.
+1
Stefan Ram
2015-12-30 20:01:57 UTC
Permalink
Post by Stefan Ram
Eine Schnittstelle erlaubt es auch, einen abstrakten
Datentyp unabhängig von einer Implementation zu
dokumentieren und diese Dokumentation zu vererben.
Ich denke, man muß hier auch zwischen »Schnittstelle im
Sinne von Java« und »Schnittstelle im Sinne von UML«
(oder GOF) unterscheiden.

Eine Schnittstelle im Sinne von Java wird häufig eingesetzt,
um eine Schnittstelle im Sinne von UML (oder GOF) zu
realisieren, aber beide Begriffe sind nicht deckungsgleich.

Beispielsweise kennen UML oder GOF wahrscheinlich keine
»default methods« oder »constant variables« in Schnittstellen,
Java aber schon.

Manchmal meint man mit »der Schnittstelle einer Klasse«
auch einfach alles, was öffentlich von der Klasse
sichtbar ist, was wieder eine andere Bedeutung ist.
(Entsprechend gibt es auch eine »Schnittstelle einer
Methode« ... und dann in Java auch »Methodenschnittstellen«).

In manchen C++-Büchern wird auch von »interfaces«
gesprochen, so schreibt Stroustrup »Use abstract classes
as interfaces to class hierarchies«, obwohl es in der
Programmiersprache C++ das Wort »interface« nicht als
Schlüsselwort in der Sprache gibt.
Marcel Mueller
2015-12-30 18:37:21 UTC
Permalink
Post by Ralf S. Hellersen
nach der Suche von mehreren Erklärungen habe ich als Wiedereinsteiger in
Welchen Vorteil bieten diese ?
Sie erhalten eine (abstrakte) Methode ohne dazugehörigen Kode, den ich
in der main-Klasse selber schreiben muss. Das bezeichne ich nicht als
Arbeitserleichterung. Ich verwende auch nicht wieder, was ein Vorteil
der objektorientierten Programmierung ist.
Es gibt viele Anwendungsgebiete. Eines ist wie der Name schon sagt, eine
definierte und (hoffentlich) dokumentierte Schnittstelle.
Ein anderes kann die Testbarkeit von Code betreffen. Ein Interface kann
man halt per Dependency Injection schnell mal durch ein Mock-Objekt
ersetzen. Eine Klasse nicht.
Proxy- oder Facade-Pattern geht ohne Interface auch nicht.
Und last but not least sind Interfaces in Java bei Mehrfachvererbung
unabdingbar.

Gerade diese erste Sache, mit der einheitlichen Schnittstelle sollte man
nicht unterschätzen. Ein Collection Framework ohne Interfaces (z.B.
Iterator) ist nahezu undenkbar. Ebenso APIs wie JDBC oder JMS.

Logisch gesehen ist eine komplett abstrakte Klasse und ein Interface
dasselbe. Technisch ist es in Java ein Unterschied, der sich unter
anderem bei der Mehrfachvererbung manifestiert. (In anderen Sprachen wie
z.B. C++ ist es auch technisch dasselbe.)


Marcel
Michael Paap
2015-12-30 19:20:33 UTC
Permalink
Post by Ralf S. Hellersen
nach der Suche von mehreren Erklärungen habe ich als Wiedereinsteiger in
Welchen Vorteil bieten diese ?
Ergänzend zu den anderen Antworten:

Interfaces erlauben dir, aus der Menge der Nachrichten, die ein Objekt
versteht, eine Teilmenge herauszugreifen, und diese als eigenen Typ zu
modellieren. Und das wiederum führt dazu, dass du Objekte zu einem Typ
zusammenfassen kannst, die nichts gemeinsam haben, außer eben, dass sie
die besagten Nachrichten verstehen, wobei sie die entsprechenden
Methoden höchst unterschiedlich implementieren können.

Dieses Bilden eines "Teil-Typs" ermöglicht es, dass Programmteile völlig
unabhängig von konkreten Implementierungen gebaut werden können: Eine
Klasse, welche ein Objekt nur in seiner Rolle als Exemplar eines
Interface-Typs kennt, ist von der tatsächlichen Klasse dieses Objekts
unabhängig und kann vollständig gebaut und übersetzt werden, ohne dass
es überhaupt schon eine das Interface implementierende Klasse geben
muss. Und das ist eine wesentliche Voraussetzung z.B. für das Schreiben
von Frameworks und generell für eine team- oder gar
unternehmensübergreifend arbeitsteilige Entwicklung.

Gruß,
Michael
Ralf S. Hellersen
2015-12-30 23:09:05 UTC
Permalink
Post by Michael Paap
Post by Ralf S. Hellersen
nach der Suche von mehreren Erklärungen habe ich als Wiedereinsteiger
Welchen Vorteil bieten diese ?
Interfaces erlauben dir, aus der Menge der Nachrichten, die ein Objekt
versteht, eine Teilmenge herauszugreifen, und diese als eigenen Typ zu
modellieren. Und das wiederum führt dazu, dass du Objekte zu einem Typ
zusammenfassen kannst, die nichts gemeinsam haben, außer eben, dass sie
die besagten Nachrichten verstehen, wobei sie die entsprechenden
Methoden höchst unterschiedlich implementieren können.
Das ist eine Antwort, die meinem jetzigen Horizont entspricht.
Post by Michael Paap
Dieses Bilden eines "Teil-Typs" ermöglicht es, dass Programmteile völlig
unabhängig von konkreten Implementierungen gebaut werden können: Eine
Klasse, welche ein Objekt nur in seiner Rolle als Exemplar eines
Interface-Typs kennt, ist von der tatsächlichen Klasse dieses Objekts
unabhängig und kann vollständig gebaut und übersetzt werden, ohne dass
es überhaupt schon eine das Interface implementierende Klasse geben
muss. Und das ist eine wesentliche Voraussetzung z.B. für das Schreiben
von Frameworks und generell für eine team- oder gar
unternehmensübergreifend arbeitsteilige Entwicklung.
Dafür werde ich nach Beispielen suchen, um es zu verstehen.

Vielen Dank für die vielen Antworten. Zur Zeit sind viele aber noch zu
theoretisch für mich.

Gruß
Ralf
Stefan Ram
2015-12-30 23:46:16 UTC
Permalink
Post by Ralf S. Hellersen
Dafür werde ich nach Beispielen suchen, um es zu verstehen.
Schnittstellen einer Klasse sind Obertypen jener Klasse.

In meinem Java-Kurs behandle ich eher Obertypen allgemein
als Schnittstellen im speziellen.

Der Kurs

http://www.purl.org/stefan_ram/pub/java-kurs

(bei Fehler 403 per Google auf die Seite gehen)

erklärt den Begriff »Obertyp« zunächst erst einmal
im Grundkurs an Hand von »int« und »double« in der
Lektion

Lektion 4.9. Aufrufwandlung in Java

. Ausführlicher werden Obertypen - einschließlich
Schnittstellen - dann im Aufbaukurs im

Kapitel 13 Obertypen und Untertypen in Java

erklärt, das viele Kursteilnehmer aber etwas »trocken«
finden.

Das folgende Kapitel 14 baut dann darauf auf.

Lektion 14.4. Objektnamen in Java

erklärt schon einige Mechanismen von Obertypen
an Hand einer Schnittstelle.

Lektion 14.6. Obertypvariablen in Java

zeigt ein Beispiel zu Obertypen als Parametertypen, ohne
/zu/ viel vorauszusetzen: dort entspricht der Obertyp
»Number« praktisch einer Schnittstelle der beiden Typen,
auch wenn »Number« in diesem Fall eine Klasse ist,
könnte es für diese Beispiel genausogut auch eine
gemeinsame Schnittstelle sein.

Das Kapitel 14 illustriert dann gegen Ende alles noch mit
JavaFX-Beispielen. Es ist allerdings noch nicht ganz
ausgearbeitet.

Alle diese Lektionen behandeln zur Vereinfachung erst einmal
vorgegebene Standardschnittstellen, noch keine vom Programm
selber definierte Schnittstellen.
Michael Paap
2015-12-31 01:35:24 UTC
Permalink
Post by Ralf S. Hellersen
Post by Michael Paap
Dieses Bilden eines "Teil-Typs" ermöglicht es, dass Programmteile völlig
unabhängig von konkreten Implementierungen gebaut werden können: Eine
Klasse, welche ein Objekt nur in seiner Rolle als Exemplar eines
Interface-Typs kennt, ist von der tatsächlichen Klasse dieses Objekts
unabhängig und kann vollständig gebaut und übersetzt werden, ohne dass
es überhaupt schon eine das Interface implementierende Klasse geben
muss. Und das ist eine wesentliche Voraussetzung z.B. für das Schreiben
von Frameworks und generell für eine team- oder gar
unternehmensübergreifend arbeitsteilige Entwicklung.
Dafür werde ich nach Beispielen suchen, um es zu verstehen.
Hier mal ein simples Beispiel... ein TicTacToe-Spiel. Wenn ich dir
folgende Klassen gebe:

public enum EFieldState {
CROSS, CIRCLE, EMPTY
}

public class PlayerException extends Exception {
public PlayerException(String message, Throwable cause) {
super(message, cause);
}

public PlayerException(String message) {
super(message);
}
}

und ein paar Interfaces festlege:

public interface ITTTModel {
EFieldState getFieldState(int row, int column);

void setFieldState(int row, int column, EFieldState state);

EFieldState[][] getFieldStates();
}

public interface ITTTView {
void refresh();
}

public interface IPlayer {
Point getMove(EFieldState[][] situation) throws PlayerException;
}

public interface IRuleMaster {
boolean isValidMove(Point move, EFieldState newState);
}


dann kannst du schon eine hübsche kleine Partie-Steuerung bauen, die
völlig unabhängig davon ist, woher konkrete Player-Klassen später ihre
Züge bekommen werden (von einem Menschen vorm Rechner, übers Netzwerk,
einer KI...), wie das Model intern implementiert ist (ein String, ein
3x3-Array, Datenbankzugriff...) oder wie das Spielfeld "ausgegeben" wird
(grafische Darstellung, ASCII auf Konsole, Sprachausgabe, Braillezeile).
Mal als "Skizze":

public class MatchController {

private IPlayer player1;

private IPlayer player2;

private ITTTModel model;

private ITTTView view;

private IRuleMaster ruleMaster;

public MatchController(IPlayer player1, IPlayer player2,
ITTTModel model, ITTTView view, IRuleMaster ruleMaster) {
this.player1 = player1;
this.player2 = player2;
this.model = model;
this.view = view;
this.ruleMaster = ruleMaster;
}

@Override
public void run() {
for (int i = 0; i < 9; i++) {
boolean even = i % 2 == 0;
IPlayer currentPlayer = even ? player1 : player2;
EFieldState nextFieldState =
even ? EFieldState.CROSS : EFieldState.CIRCLE;
boolean moved = false;
try {
while (!moved) {
Point move = currentPlayer.
getMove(model.getFieldStates());
if (ruleMaster.isValidMove(move, nextFieldState)) {
model.setFieldState(
move.x, move.y, nextFieldState);
view.refresh();
moved = true;
} else {
// Problembehandlung
}
}
} catch (PlayerException e) {
// Exceptionhandling
}
}
}
}

Das Bauen der Klassen, welche die Interfaces implementieren, können
derweil andere Mitarbeiter erledigen. ;-)

Gruß,
Michael
Ralf S. Hellersen
2015-12-31 12:46:44 UTC
Permalink
Dann bedanke ich mich noch einmal für die reichhaltigen Angaben.
Ich sehe mir alles mit Ruhe an und versuche es zu verstehen.

Gruß
Ralf
M. Strobel
2016-01-04 21:58:29 UTC
Permalink
Post by Ralf S. Hellersen
Dann bedanke ich mich noch einmal für die reichhaltigen Angaben.
Ich sehe mir alles mit Ruhe an und versuche es zu verstehen.
Hoffentlich stehen in einer der Erklärungen die magischen Worte die Dir
weiterhelfen.

Das Problem ist im Grunde:

Java hat keine Mehrfach-Vererbung, ich kann nicht von 2 verschiedenen Klassen(bäumen)
erben. Das bringt Design-Einschränkungen mit sich.

Um das Problem der fehlenden Quer-Vererbung zu mildern wurden die Interfaces
erfunden. Vorteil: der Compiler weiss dass die im Interface definierten Methoden
verfügbar sind und sein müssen.

Nachteil: es ist kein Code damit verbunden.

----------------
Es geht noch einfacher: das ist so in Java, arbeite damit,
irgendwann macht es "klick" und Du hast etwas verstanden.

/Str.
Michael Paap
2016-01-04 22:40:23 UTC
Permalink
Post by M. Strobel
Java hat keine Mehrfach-Vererbung, ich kann nicht von 2 verschiedenen Klassen(bäumen)
erben. Das bringt Design-Einschränkungen mit sich.
Um das Problem der fehlenden Quer-Vererbung
Was ist "Quer-Vererbung"? Dabei fällt mir höchstens so etwas wie die
Traits in Scala ein.
Post by M. Strobel
zu mildern wurden die Interfaces erfunden.
Ich halte das für ein Gerücht (um nicht "Bullshit!" zu rufen).

1. Mehrfachvererbung vermisst man in erster Linie, wenn man Programme,
die in Sprachen mit MV entworfen wurden, portieren möchte. Wenn man von
vornherein davon ausgeht, keine MV zur Verfügung zu haben, halten sich
die Einschränkungen doch sehr in Grenzen. Wenn man unter fehlender MV so
sehr leiden würde, wieso haben dann "jüngere" Sprachen als Java wie etwa
C# (das ja immerhin Einiges von C++ übernommen hat) oder Scala keine MV?
An neueren (praxisrelevanten) Programmiersprachen mit MV fällt mir
eigentlich nur Python ein.

2. Überall dort, wo Java professionell eingesetzt wird, findet man
allerorten Interfaces. Warum das so ist, wurde in diesem Thread ja
beschrieben.

Die Fälle, in denen Interfaces wirklich verwendet werden, um
irgendwelche Probleme zu lösen, die sich aus dem Nichtvorhandensein von
MV in Java ergeben, dürfte man darunter mit der Lupe suchen müssen.
Derlei Beispiele findet sich vor allem in Java-Büchern fragwürdiger
Qualität, mit dem Effekt, dass deren Leser nie wirklich verstehen, wozu
Interfaces sinnvoll sind und warum ihre explizite Einführung als
Sprachmittel in Java einer der (wenigen) interessanten konzeptionellen
Beiträge von Java zur OOP ist.

Gruß,
Michael
Patrick Roemer
2016-01-04 23:13:12 UTC
Permalink
Post by Michael Paap
Post by M. Strobel
Um das Problem der fehlenden Quer-Vererbung
Was ist "Quer-Vererbung"? Dabei fällt mir höchstens so etwas wie die
Traits in Scala ein.
Da sehe ich auf Anhieb auch nichts, was mit "quer" treffend beschrieben
wäre...?
Post by Michael Paap
Post by M. Strobel
zu mildern wurden die Interfaces erfunden.
Ich halte das für ein Gerücht (um nicht "Bullshit!" zu rufen).
| Multiple inheritance - and all the problems it generates - was
| discarded from Java. The desirable features of multiple inheritance
| are provided by interfaces - conceptually similar to Objective C
| protocols.
http://www.oracle.com/technetwork/java/simple-142616.html#4090

| Interfaces were introduced to Java to enhance Java's single
| inheritance model. The designers of Java decided that multiple
| inheritance created too many problems for programmers and compiler
| writers, and decided that a single inheritance model was better
| overall. Some of the problems described in the previous discussion on
| the single-inheritance model are solved in a more elegant fashion by
| the use of interfaces.
http://www.oracle.com/technetwork/java/object-142075.html#6185

Im Nachhinein könnte man die Designentscheidung für Interfaces
vielleicht eleganter rationalisieren. Aber 1996 hat James Gosling das so
beschrieben, und wesentlich andere Darstellungen aus seiner Feder kenne
ich nicht. Das kann man IMHO durchaus erst mal so zusammenfassen, dass
Interfaces "erfunden" wurden, um die Probleme fehlender
Mehrfachvererbung zu mildern. Das ist vielleicht nicht die ganze
Geschichte, aber sicher auch kein Bullshit.

Viele Grüße,
Patrick
Michael Paap
2016-01-05 00:40:53 UTC
Permalink
Post by Patrick Roemer
Im Nachhinein könnte man die Designentscheidung für Interfaces
vielleicht eleganter rationalisieren. Aber 1996 hat James Gosling das so
beschrieben, und wesentlich andere Darstellungen aus seiner Feder kenne
ich nicht. Das kann man IMHO durchaus erst mal so zusammenfassen, dass
Interfaces "erfunden" wurden, um die Probleme fehlender
Mehrfachvererbung zu mildern. Das ist vielleicht nicht die ganze
Geschichte, aber sicher auch kein Bullshit.
Ok, zur Kenntnis genommen. War mir so nicht bekannt. Sorry @ M.Strobel.

Dann sage ich es mal anders: Für die wichtige Rolle, die Interfaces
*heute* spielen, ist "Ausgleich für fehlende Mehrfachvererbung" ziemlich
irrelevant. D'accord?

Gruß,
Michael
Thomas Grund
2016-01-05 07:54:23 UTC
Permalink
Post by Michael Paap
Dann sage ich es mal anders: Für die wichtige Rolle, die Interfaces
*heute* spielen, ist "Ausgleich für fehlende Mehrfachvererbung" ziemlich
irrelevant. D'accord?
D'accord! Gegenfrage: Der heutige Einsatz von Interfaces ist ja vor
allem, die Austauschbarkeit der Implementierungen sicherzustellen (also
z.B. OpenJPA durch Hibernate ersetzen zu können, ohne den Code ändern zu
müssen). Kann man etwas Vergleichbares auch ohne Interfaces?

Thomas
Florian Weimer
2016-01-07 20:31:59 UTC
Permalink
Post by Thomas Grund
Post by Michael Paap
Dann sage ich es mal anders: Für die wichtige Rolle, die Interfaces
*heute* spielen, ist "Ausgleich für fehlende Mehrfachvererbung" ziemlich
irrelevant. D'accord?
D'accord! Gegenfrage: Der heutige Einsatz von Interfaces ist ja vor
allem, die Austauschbarkeit der Implementierungen sicherzustellen
(also z.B. OpenJPA durch Hibernate ersetzen zu können, ohne den Code
ändern zu müssen). Kann man etwas Vergleichbares auch ohne Interfaces?
Mit abstrakten Klassen geht das. Ältere Java-APIs machen das auch
(z.B. java.io.InputStream), weil der Klassen-basierte Methodenaufruf
ohne JIT-Compiler so viel schneller ist als der Umweg über Interfaces.
Thomas Grund
2016-01-08 05:56:39 UTC
Permalink
Post by Florian Weimer
Post by Thomas Grund
D'accord! Gegenfrage: Der heutige Einsatz von Interfaces ist ja vor
allem, die Austauschbarkeit der Implementierungen sicherzustellen
(also z.B. OpenJPA durch Hibernate ersetzen zu können, ohne den Code
ändern zu müssen). Kann man etwas Vergleichbares auch ohne Interfaces?
Mit abstrakten Klassen geht das. Ältere Java-APIs machen das auch
(z.B. java.io.InputStream), weil der Klassen-basierte Methodenaufruf
ohne JIT-Compiler so viel schneller ist als der Umweg über Interfaces.
Stimmt. Sie müssen nicht mal abstrakt sein. Interfaces machen halt
(nomen est omen) die Schnittstellen deutlicher.

Und da wäre noch die Mehrfachvererbung: Bei

class A implements B, C {}

kann man A wahlweise in B oder C injizieren. Allerdings habe ich dafür
noch keine Anwendung gesehen.

Thomas
Florian Weimer
2016-03-28 18:23:44 UTC
Permalink
Post by Thomas Grund
Post by Florian Weimer
Post by Thomas Grund
D'accord! Gegenfrage: Der heutige Einsatz von Interfaces ist ja vor
allem, die Austauschbarkeit der Implementierungen sicherzustellen
(also z.B. OpenJPA durch Hibernate ersetzen zu können, ohne den Code
ändern zu müssen). Kann man etwas Vergleichbares auch ohne Interfaces?
Mit abstrakten Klassen geht das. Ältere Java-APIs machen das auch
(z.B. java.io.InputStream), weil der Klassen-basierte Methodenaufruf
ohne JIT-Compiler so viel schneller ist als der Umweg über Interfaces.
Stimmt. Sie müssen nicht mal abstrakt sein. Interfaces machen halt
(nomen est omen) die Schnittstellen deutlicher.
Und da wäre noch die Mehrfachvererbung: Bei
class A implements B, C {}
kann man A wahlweise in B oder C injizieren. Allerdings habe ich dafür
noch keine Anwendung gesehen.
Man kann immer (*) eine Methode schreiben, die ein Proxy-Objekt für A
zurückgibt, welches die Methoden von B oder C bereitstellt.

(*) Es gibt ggf. Probleme, das vollständig typsicher hinzubekommen,
aber den Effekt hat man auch bei Interfaces wie Comparable<T>.

Lothar Kimmeringer
2016-01-08 18:13:57 UTC
Permalink
Post by Florian Weimer
Post by Thomas Grund
D'accord! Gegenfrage: Der heutige Einsatz von Interfaces ist ja vor
allem, die Austauschbarkeit der Implementierungen sicherzustellen
(also z.B. OpenJPA durch Hibernate ersetzen zu können, ohne den Code
ändern zu müssen). Kann man etwas Vergleichbares auch ohne Interfaces?
Mit abstrakten Klassen geht das. Ältere Java-APIs machen das auch
(z.B. java.io.InputStream), weil der Klassen-basierte Methodenaufruf
ohne JIT-Compiler so viel schneller ist als der Umweg über Interfaces.
java.io.InputStream hat viel implementiert, so dass ich das als
Beispiel irgendwie nicht gelten lassen kann. Wuerde man InputStream
als Interface haben, muesste jede Implementierung zwei read-
Methoden, available, reset, markSupported, etc. implementieren
statt nur public int read() throws IOException.

Und das mit den unterschiedlichen Ausfuehrungszeiten haette
ich gerne einmal in Zahlen. Davon hoere ich jetzt zum ersten mal.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

--- news://freenews.netfront.net/ - complaints: ***@netfront.net ---
Stefan Ram
2016-01-05 01:10:11 UTC
Permalink
Post by Patrick Roemer
Im Nachhinein könnte man die Designentscheidung für Interfaces
vielleicht eleganter rationalisieren. Aber 1996 hat James Gosling das so
beschrieben, und wesentlich andere Darstellungen aus seiner Feder kenne
ich nicht. Das kann man IMHO durchaus erst mal so zusammenfassen, dass
Interfaces "erfunden" wurden, um die Probleme fehlender
Mehrfachvererbung zu mildern. Das ist vielleicht nicht die ganze
Geschichte, aber sicher auch kein Bullshit.
Ich wünschen allen einen guten Morgen! 2016 haben wir
»default«-Methoden in Schnittstellen und damit praktisch
volle Mehrfachvererbung, einschließlich des Diamantproblems.
Patrick Roemer
2016-01-05 01:35:54 UTC
Permalink
Post by Stefan Ram
Post by Patrick Roemer
Im Nachhinein könnte man die Designentscheidung für Interfaces
vielleicht eleganter rationalisieren. Aber 1996 hat James Gosling das so
beschrieben, und wesentlich andere Darstellungen aus seiner Feder kenne
ich nicht. Das kann man IMHO durchaus erst mal so zusammenfassen, dass
Interfaces "erfunden" wurden, um die Probleme fehlender
Mehrfachvererbung zu mildern. Das ist vielleicht nicht die ganze
Geschichte, aber sicher auch kein Bullshit.
Ich wünschen allen einen guten Morgen! 2016 haben wir
»default«-Methoden in Schnittstellen und damit praktisch
volle Mehrfachvererbung, einschließlich des Diamantproblems.
Ich gehe davon aus, dass Herr Gosling im Jahr 1996 deutlich anders
gedacht gehabt wird, sobald er von diesem Umstand erfahren gehabt wurde.
Mir liegt aber derzeit leider nur das veraltete Exemplar seines Papers
aus der präzyklischen Historie vor. :(

Viele Grüße,
Patrick
Michael Paap
2016-01-05 08:06:48 UTC
Permalink
Post by Stefan Ram
Ich wünschen allen einen guten Morgen! 2016 haben wir
»default«-Methoden in Schnittstellen und damit praktisch
volle Mehrfachvererbung, einschließlich des Diamantproblems.
Lustigerweise haben wir die Default-Methoden aber nicht, weil man MV
wollte, sondern wir haben sie, weil man auf diese Weise eine
Weiterentwicklung bestehender Interfaces ermöglichen will.

Ansonsten sieht man heute Vererbung ohnehin ganz anders als früher. Um
es mal etwas provokant zu formulieren: Wer braucht denn mehrfaches
Subclassing, wenn man Subclassing meist ohnehin zugunsten von Delegation
vermeidet? ;-)

Gruß,
Michael
Patrick Roemer
2016-01-05 13:38:34 UTC
Permalink
Post by Michael Paap
Post by Stefan Ram
Ich wünschen allen einen guten Morgen! 2016 haben wir
»default«-Methoden in Schnittstellen und damit praktisch
volle Mehrfachvererbung, einschließlich des Diamantproblems.
Lustigerweise haben wir die Default-Methoden aber nicht, weil man MV
wollte, sondern wir haben sie, weil man auf diese Weise eine
Weiterentwicklung bestehender Interfaces ermöglichen will.
Das mag insofern stimmen, als es auch Interfaces nur gibt, um die
Schmerzen fehlender Mehrfachvererbung zu lindern. :) IOW: Das mag der
Hauptauslöser gewesen sein. Jetzt ist die Frage, was man draus macht...

Nehmen wir mal Function in Java 8. Das Interface gab es vorher nicht,
die Defaultmethoden können also nicht eingebaut worden sein, um
bestehenden Code nicht kaputtzumachen. Würde man das als reines
Interface mit drei abstrakten Methodendeklarationen realisieren wollen?
Ungern, denn die Implementierung von #andThen() und #compose() basierend
auf #apply() ist wirklich kanonisch - warum sollte jeder Implementor von
Function den Boilerplate erneut runtertippen sollen? Oder könnte das
genausogut eine abstrakte Klasse sein? Auch nicht wirklich, denn viele
Konzepte haben implizite Funktionssemantik, und man wird den "primären
Vererbungspfad" öfter mal für das eigentliche Konzept brauchen. Kann man
das anders machen? Klar: Statische Methoden, Wrapperobjekte... Aber die
gegebene Implementierung erscheint mir als die natürlichste. Und damit
halte ich das schon für ein halbwegs valides Beispiel für die Nutzung
von "Multiple Inheritance" via Defaultmethoden zur Realisierung von
"Rich Interfaces". Und die JDK-Entwickler bei Oracle scheinen das
ähnlich gesehen zu haben.
Post by Michael Paap
Ansonsten sieht man heute Vererbung ohnehin ganz anders als früher. Um
es mal etwas provokant zu formulieren: Wer braucht denn mehrfaches
Subclassing, wenn man Subclassing meist ohnehin zugunsten von Delegation
vermeidet? ;-)
Wer braucht denn dann überhaupt Subclassing? Ach so, "meist"...

Multiple Inheritance (in welcher Form auch immer) braucht man noch
deutlich seltener als Single Inheritance, und man sollte ihren Einsatz
noch skeptischer hinterfragen. Aber wenn sie mal sinnvoll und angebracht
ist, ist sie nur sehr mühsam nachzubilden, wenn die Sprache sie nicht
bietet.

Viele Grüße,
Patrick
Stefan Ram
2016-01-05 14:01:29 UTC
Permalink
Post by Patrick Roemer
Nehmen wir mal Function in Java 8. Das Interface gab es vorher nicht,
die Defaultmethoden können also nicht eingebaut worden sein, um
bestehenden Code nicht kaputtzumachen. Würde man das als reines
Interface mit drei abstrakten Methodendeklarationen realisieren wollen?
Außerdem wäre java.util.function.Function mit mehr als einer
abstrakte Methode dann ja keine funktionale Schnittstelle mehr.
Patrick Roemer
2016-01-05 16:06:23 UTC
Permalink
Post by Stefan Ram
Post by Patrick Roemer
Nehmen wir mal Function in Java 8. Das Interface gab es vorher nicht,
die Defaultmethoden können also nicht eingebaut worden sein, um
bestehenden Code nicht kaputtzumachen. Würde man das als reines
Interface mit drei abstrakten Methodendeklarationen realisieren wollen?
Außerdem wäre java.util.function.Function mit mehr als einer
abstrakte Methode dann ja keine funktionale Schnittstelle mehr.
Das ist in der Tat ein weiterer, ganz unerheblicher Nebeneffekt. ;)
Dieselbe Technik findet sich aber auch bei anderen, nicht-funktionalen
Interfaces, z.B. Spliterator.

Viele Grüße,
Patrick
Florian Weimer
2016-01-07 20:43:49 UTC
Permalink
Post by Patrick Roemer
Nehmen wir mal Function in Java 8. Das Interface gab es vorher nicht,
die Defaultmethoden können also nicht eingebaut worden sein, um
bestehenden Code nicht kaputtzumachen. Würde man das als reines
Interface mit drei abstrakten Methodendeklarationen realisieren wollen?
Ungern, denn die Implementierung von #andThen() und #compose() basierend
auf #apply() ist wirklich kanonisch - warum sollte jeder Implementor von
Function den Boilerplate erneut runtertippen sollen? Oder könnte das
genausogut eine abstrakte Klasse sein? Auch nicht wirklich, denn viele
Konzepte haben implizite Funktionssemantik, und man wird den "primären
Vererbungspfad" öfter mal für das eigentliche Konzept brauchen.
Ich glaube, man wollte eher die automatisch erzeugten Funktionsobjekte
komplett leer haben, ohne Variablen und ohne Konstruktor.
Patrick Roemer
2016-01-08 16:15:55 UTC
Permalink
Post by Florian Weimer
Post by Patrick Roemer
Nehmen wir mal Function in Java 8. Das Interface gab es vorher nicht,
die Defaultmethoden können also nicht eingebaut worden sein, um
bestehenden Code nicht kaputtzumachen. Würde man das als reines
Interface mit drei abstrakten Methodendeklarationen realisieren wollen?
Ungern, denn die Implementierung von #andThen() und #compose() basierend
auf #apply() ist wirklich kanonisch - warum sollte jeder Implementor von
Function den Boilerplate erneut runtertippen sollen? Oder könnte das
genausogut eine abstrakte Klasse sein? Auch nicht wirklich, denn viele
Konzepte haben implizite Funktionssemantik, und man wird den "primären
Vererbungspfad" öfter mal für das eigentliche Konzept brauchen.
Ich glaube, man wollte eher die automatisch erzeugten Funktionsobjekte
komplett leer haben, ohne Variablen und ohne Konstruktor.
Das mag auch durchaus sein. Function war aufgrund seiner Sonderstellung
wohl ein etwas ungünstiges Beispiel. Aber wie gesagt, das Muster findet
sich auch in anderen Interfaces, wo derartige Überlegungen keine Rolle
spielen sollten.

Viele Grüße,
Patrick
Ralf S. Hellersen
2016-01-09 20:45:18 UTC
Permalink
.. mit dem Effekt, dass deren Leser nie wirklich verstehen, wozu
Interfaces sinnvoll sind und warum ihre explizite Einführung als
Sprachmittel in Java einer der (wenigen) interessanten konzeptionellen
Beiträge von Java zur OOP ist.
Genau das war mein Problem.

Gruß
Ralf
Lothar Kimmeringer
2015-12-30 19:50:57 UTC
Permalink
Post by Ralf S. Hellersen
Sie erhalten eine (abstrakte) Methode ohne dazugehörigen Kode, den ich
in der main-Klasse selber schreiben muss. Das bezeichne ich nicht als
Arbeitserleichterung. Ich verwende auch nicht wieder, was ein Vorteil
der objektorientierten Programmierung ist.
Es gab ja schon ein paar Antworten, hier noch ein paar
weitere Anwendungsgebiete:

- RMI bzw. CORBA waere ohne Interfaces nicht moeglich. Das
Interface erlaubt dir, Funktionen aufzurufen, deren reale
Klassen nicht zwingend lokal vorliegen.
- Proxies (im Zusammenhang mit Reflection) koennen auch nur
gegen implementierte Interfaces einer Klasse gebaut werden,
auch das ganze Thema dynamische Codegenierierung (Proxies
sind da nur ein Teilbereich) funktioniert besser damit.
- Du kannst eine Klasse mehr als ein Interface implementieren
lassen, als von Klassen ableiten.
- Interfaces muessen nicht zwangslaeufig Methoden deklarieren,
sondern koennen auch einfach nur als "Marker" verwendet werden.
Als Beispiel sei hier aus dem JDK mal java.io.Serializable genannt.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

--- news://freenews.netfront.net/ - complaints: ***@netfront.net ---
Lesen Sie weiter auf narkive:
Suchergebnisse für 'Grundsätzliche Frage zu Interfaces' (Fragen und Antworten)
3
Antworten
Kann ich meinen Verstärker direkt an mein Audio-Interface anschließen?
gestartet 2014-07-18 00:30:02 UTC
musik
2
Antworten
Wie berechne ich das Übersetzungsverhältnis, um ein Gewicht mit konstanter Geschwindigkeit zu heben?
gestartet 2015-03-10 10:29:21 UTC
maschinenbau
5
Antworten
Ist es möglich, mit einem NRF24L01 + ohne Arduino zu senden?
gestartet 2014-05-21 16:26:20 UTC
arduino
8
Antworten
Ist es möglich zu "fälschen", mit einem Router verbunden zu sein?
gestartet 2017-04-27 05:19:00 UTC
sicherheit
15
Antworten
Wie kann ich Nichteltern sagen: "Warten Sie ab, bis Sie Kinder haben", ohne klischeehaft und widerlich zu sein?
gestartet 2017-08-17 19:45:54 UTC
zwischenmenschlich
Nicht verwandte, aber interessante Themen
6
Antworten
Stimmt es, dass es in Europa im Durchschnitt einfacher ist, einen Doktortitel zu erhalten als in den USA?
gestartet 2012-09-30 15:22:46 UTC
6
Antworten
Wir haben festgestellt, dass ein Co-Autor vor 8 Jahren Plagiate in unser Papier eingefügt hat - was ist jetzt zu tun?
gestartet 2020-01-25 21:57:54 UTC
5
Antworten
Kann ich einen Abschnitt "Autorenbeiträge" hinzufügen, um zu verdeutlichen, dass ich alle Arbeiten an einem Papier durchgeführt habe?
gestartet 2018-12-18 10:59:54 UTC
6
Antworten
Welche Art von Karriereweg könnte für einen Professor nach einem Plagiatsskandal möglich sein?
gestartet 2014-11-07 03:11:44 UTC
8
Antworten
Ist das Ignorieren von E-Mails im akademischen Bereich akzeptabel?
gestartet 2013-04-22 05:50:04 UTC
Loading...