Wieso spricht man bei einem Interface von einer Entkopplung,

[JJ (Gast)]

wenn man bei der Objekterzeugung zur Compilezeit immer noch konkret 
wissen muss, was für ein Typ eines Objekts erzeugt werden soll.

Mal angenommen mein interface heißt Fisch und die Klasse, die das 
interface implementieren soll, die heißt Hai, dann muss ich bei der 
Objekterzeugung meiner Klasse Hauptprogramm ja immer noch sagen, was 
für ein Objekt vom Typ interface sie erzeugen soll.

Also z.b. in main() von Hauptprogramm:

public static void main(String[] args) {
  // geht
  Fisch fish = Hai();

  // geht nicht:
  Fisch fish = Fisch();
  ...

Entkoppelt sind da ja nur die Methoden und Attribute, falls es welche 
über das Interface gibt und wenn ich auf die dann von Hauptprogramm aus 
zugreife, aber nicht der Name der Klasse die das Interface 
implementiert.

[Sina A. (sinapse)]

hmm... bin mir nicht ganz sicher, ob ich deine frage richtig verstehe, 
aber stell dir vor du hast noch eine klasse kugel, die ebenfalls das 
interface fisch implementiert, dann kann man sehr einfach in deinem 
programm hai durch kugel ersetzen. deshalb redet man von entkopplung von 
fisch und hai/kugel.

du kannst dann auch einen zeiger vom typ fisch haben und erst zur 
laufzeit den zeiger auf hai oder kugel zeigen lassen. dann wird die 
entkopplung deutlicher

lg

[Roland P. (pram)]

Ausserdem gibt es noch die Möglichkeit per Classpathscanning / 
Configfile sich eine Factory zu suchen, die die Tiere instanziiert.
In deinem Fall sucht man nach einer WassertierFactory und ruft darauf 
die Methode createFisch() auf.

[Clemens L. (c_l)]

JJ schrieb:
> wenn man bei der Objekterzeugung zur Compilezeit immer noch konkret
> wissen muss, was für ein Typ eines Objekts erzeugt werden soll.

Und selbst wenn du das in eine Factory verschiebst, dann gibt es halt 
dort den Code, der den konkreten Typ wissen muss. (Und wenn wir mal 
annehmen, dass es keinen solche Code gibt: woher soll dann der Rechner 
wissen, was für ein Objekt er erzeugen soll?)

Der Punkt ist, dass der ganze restliche Code entkoppelt ist.

[D. I. (Gast)]

Clemens L. schrieb:
> Und selbst wenn du das in eine Factory verschiebst, dann gibt es halt
> dort den Code, der den konkreten Typ wissen muss. (Und wenn wir mal
> annehmen, dass es keinen solche Code gibt: woher soll dann der Rechner
> wissen, was für ein Objekt er erzeugen soll?)
>
> Der Punkt ist, dass der ganze restliche Code entkoppelt ist.

Spring ist dir bekannt?

[Clemens L. (c_l)]

D. I. schrieb:
> Spring ist dir bekannt?

Dann gibt es halt eine XML-Datei, die den konkreten Typ wissen muss.

[Borislav B. (boris_b)]

Clemens L. schrieb:
> Dann gibt es halt eine XML-Datei, die den konkreten Typ wissen muss.

Ja und? Worauf willst du hinaus?

[D. I. (Gast)]

Clemens L. schrieb:
> D. I. schrieb:
>> Spring ist dir bekannt?
>
> Dann gibt es halt eine XML-Datei, die den konkreten Typ wissen muss.

Richtig, damit muss der Code nicht mehr angefasst werden wenn man einen 
konkreten Typen austauschen will.
Ist ja wohl logisch, dass IRGENDWER den konkreten Typen angeben muss. 
Üblicherweise macht das aber nicht mehr die verwendende Komponente, 
diese gibt nur das Interface vor, Stichworte Dependency Injection und 
Inversion of Control.

[Jack (Gast)]

JJ schrieb:
> wenn man bei der Objekterzeugung zur Compilezeit immer noch
> konkret
> wissen muss, was für ein Typ eines Objekts erzeugt werden soll.

Das sind die üblichen großen Sprüche der Informatiker. Bei denen muss 
man immer sorgfältig ins "Kleingedruckte" schauen:

Interfaces reduzieren die Kopplung und erlauben dadurch mehr Kontrolle 
darüber, wo man die konkreten Instanzen erzeugt.