Hallo,

ich finde immer wieder Beispiele bei Deklarationen wie dieses:

markieren

Code:

Collection<String> strings = new LinkedList<String>();

Was ist der tiefere Sinn darin, strings als Oberklasse zu definieren? LinkedList<String> ist ja eine Unterklasse zu Collection <Strings>. D.h auch, dass ich z.B. in Methoden überall wo eine Collection<String> erwartet wird, auch jede Unterklasse angeben kann. Warum deklariert man dann nicht:

markieren

Code:

LinkedList<String> strings = new LinkedList<String>();

Welchen Vorteil hat die obere Version?

(Weg-)Kapselung der Implementierungsdetails.

Vielleicht war der Code früher nur eine Collection<String>. Und wird auch nur als solche benutzt. Später fällt jemandem auf, dass die LinkedList<String> bei der Verwendung eine bessere Performance hat. Dabei muss/braucht dann der Rest vom Code, der auf der Basisklasse aufsetzt, nicht geändert werden.

Innerhalb einer einzelnen Methode ist das jetzt nicht so tragisch, aber spätestens wenn ein Objekt den Scope verlässt (Rückgabewert aus Methoden) versuche ich wo immer möglich den kleinsten benötigten Nenner zu finden und nutze diesen als Typangabe bzw. gar ein Interface. Um eben die eigentlichen Details der Implementierung wegzukapseln.

Das verstehe ich nur teilweise. Der Basiscode muss ja auch dann nicht geändert werden, wenn man den Typen so wie in der 2. Version oben angibt. Denn überall da, wo ich eine Klasse oder ein Interface einsetze, kann ich ja auch eine Unterklasse oder ein Unter-Interface einsetzen. Wenn der Rückgabewert einer Methode den Typ einer Klasse hat, jetzt aber eine Unterklasse bekommt, kann der Basiscode damit problemlos umgehen.

Zitat von MrSpock:

Denn überall da, wo ich eine Klasse oder ein Interface einsetze, kann ich ja auch eine Unterklasse oder ein Unter-Interface einsetzen. Wenn der Rückgabewert einer Methode den Typ einer Klasse hat, jetzt aber eine Unterklasse bekommt, kann der Basiscode damit problemlos umgehen.

Das ist korrekt und in solchen Fällen ist es austauschbar ob Du den einen oder den anderen Weg nimmst. Tatsächlich ist es auch eher Sinnvoll in den Methodensignaturen auf die Verwendung eines möglichst abstrakten Typen zu achten.

Zitat von MrSpock:

Der Basiscode muss ja auch dann nicht geändert werden, wenn man den Typen so wie in der 2. Version oben angibt.

Das muss so nicht stimmen. Du kannst in der ersten Variante mit Strings nur das machen, was mit einer beliebigen Collection möglich ist, in der zweiten zusätzlich auch das, was speziell für eine LinkedList gilt.
Das heißt klar, überall da, wo Du nur irgendeine Collection erwartest funktioniert alles wie Du möchtest, ganz ohne Änderung. Was aber wenn Du folgende (rein fiktive) Klasse erzeugst:

markieren

Code:

public class LinkedListUtils {
  public static LinkedList performMagic(final LinkedList list) {
    // do some magic...
  }
}

Der Aufruf dieser Methode ist nur für die zweite Methode möglich. Das Beispiel mag jetzt ziemlich konstruiert wirken, aber nimm einfach die Klasse Collections oder so, auch hier kann sich schließlich der Autor (trotz des guten Namen) vertippen und statt List eine ArrayList einfügen. Im Test fällt das sofort auf, wenn das getestet Objekt eben vom Typ List ist, wählst Du aber (zufällig) auch noch eine LinkedList die Du übergibst, hast Du ein Problem.

Auch für das Refactoren kann diese Unterscheidung helfen. So hast Du in Beispiel 1 nur solche Methoden zur Verfügung, die eine Collection hat, in der zweiten aber schon alles, was eine LinkedList bietet. Jetzt kann es sein, dass Du den Code für eine spezielle Implementierung erstellst und erst nach und nach merkst, dass Du die Methode doch abstrakter nutzen möchtest und vielleicht zwei Methoden daraus machst, zudem wird die Collection übergeben. Jetzt willst Du aber gezielt auf ein bestimmtes Element zugreifen, z.B. das erste oder letzte, für eine java.util.List kein Problem, für eine Collection (z.B. ein HashSet) nicht möglich, da es keine Sortierung in Mengen gibt.