Interface Datentyp bei Erzeugung eines Objekts, dessen Klasse eine Schnittstelle implementiert

[ratnalein]

Hallo zusammen,

ich versuche schon seit Stunden, dieses eine Thema zu verstehen:

public interface MyInterface {

    public String hello = "Hello";

    public void sayHello();
}

public class MyInterfaceImpl implements MyInterface {
    public int echteMethode(){
        return 5;
    }
    public void sayHello() {
        System.out.println(MyInterface.hello);
    }
}

MyInterface myInterface = new MyInterfaceImpl();

myInterface.sayHello();

Es wird oft gesagt, dass der Datentyp von myInterface MyInterface sein soll, statt MyInterfaceImpl. Ich verstehe es nicht, warum. Oft wird diese Frage bzw. diese Thematik in Verbindung mit einer weiteren Klasse gebracht, die ebenfalls MyInterface implementiert. Angenommen, wir haben jene Klasse:

public class MyInterfaceImplZwei implements MyInterface {
    public int echteMethodeZwei(){
        return 6;
    }
    public void sayHello() {
        System.out.println(MyInterface.hello);
    }
}

Als Vorteil wird geschildert.. wenn man für die Objekterzeugung folgendes schreibt:

MyInterface objektInterface = new MyInterfaceImpl();

statt:

MyInterfaceImpl objektInterface = new MyInterfaceImpl();

,dann braucht man im Folgecode nichts mehr umzuändern, außer des Datentypen von objektInterface. Ich frage mich, wieso?
Könnte mir jemand bitte helfen?

Lieben Dank.

Schöne Grüße aus Rheinland,

Eure Ratna

 

[Marco13]

Hm. "Nichts mehr zu ändern" ist vielleicht etwas mißverständlich. Wenn ÜBERALL im Code nur sowas steht wie

objektInterface.sayHello();

dann ist natürlich egal, ob die Variable als
MyInterface objektInterface = ... oder
MyInterfaceImpl objektInterface = ... oder
MyInterfaceImplZwei objektInterface = ...
definiert ist. Das ist aber nicht die Regel.

Die Schwierigkeiten treten auf, wenn sich jemand (und sei es nur "versehentlich") an irgendeiner Stelle auf einen besimmten Typ verläßt:

class MyInterfaceImplZwei implements MyInterface 
{
    ...
    // Wie vorher, aber zusätzlich:
    public void sayGoodbye() { System.out.println("to flexibility and abstraction"); }
}

und dann die Variable als
MyInterfaceImplZwei objektInterface = ...
deklariert ist, und irgendwo jemand
objektInterface.sayGoodbye();
aufruft. Dann funktioniert dieser Code auf einmal NUR noch mit dem MyInterfaceImplZwei.

Deutlicher wird es bei Methodensignaturen. Wenn irgendwo eine Methode steht wie

public void letHimSayHello(MyInterface object)
{
    object.sayHello();
}

Dann kann man dort jedes beliebige Objekt übergeben, das das Interface implementiert. Egal ob "Impl" oder "ImplZwei". Wenn man aber von vornherein

public void letHimSayHello(MyInterfaceImpl object)
{
    object.sayHello();
}

schreibt, funktioniert es wieder nur mit 'Impl', und nicht mit irgendwas anderem.


Ganz konkret: Mir läuft es immer kalt den Rücken runter, wenn ich sowas sehe wie

public void doSomething(ArrayList<String> list) { ... }

weil man dort NUR eine ArrayList übergeben kann. Wenn man

public void doSomething(List<String> list) { ... }

schreiben würde, könnte man nicht nur ArrayLists, sondern auch Vectors, LinkedLists und alle anderen Lists dort übergeben.

 

[Timothy Truckle]

,dann braucht man im Folgecode nichts mehr umzuändern, außer des Datentypen von objektInterface. Ich frage mich, wieso?

So richtig interessant wird die Sache ja erst bei der Verwendung in Colletions:

Set<MyInterface> mySet = new Hashset<>();
mySet.add(new MyInterfaceImpl());
mySet.add(new MyInterfaceImplZwei());
for(MyInterface myInterface:mySet) {
   myInterface.sayHallo();
}

Un jetzt stell Dir mal vor,

sayHallo()

wäre in den beiden Implementierungen anders ausgeführt:

public class MyInterfaceImpl implements MyInterface {
       public void sayHello() {
        System.out.println(MyInterface.hello);
    }
}
public class MyInterfaceImplZwei implements MyInterface {
    public void sayHello() {
        MessageFormat.format("MyInterfaceImplZwei says {0} to the world",MyInterface.hello);
    }
}

Obwohl Du in der for Schleife immer die selbe Methode aufrufst passiert bei jedem Objekt etwas anderes.
Das nennt man Polymorphie.

Die lässt sich auch mit "normaler" Vererbung erreichen, aber über Interfaces ist die Sache viel einfacher zu handhaben.

bye
TT

 

[ratnalein]

Hallo zusammen,

@Marco13,

und dann die Variable als
MyInterfaceImplZwei objektInterface = ...
deklariert ist, und irgendwo jemand
objektInterface.sayGoodbye();
aufruft. Dann funktioniert dieser Code auf einmal NUR noch mit dem MyInterfaceImplZwei.

Aber das ändert doch nichts daran, dass frau hierbei auch etwas umändern muss, nämlich von:

MyInterface objektInterface = new MyInterfaceImpl();

auf

MyInterface objektInterface = new MyInterfaceImplZwei();

Bei meiner Version wäre doch auch lediglich EINE Änderung notwendig, nämlich von:

MyInterfaceImpl objektInterface = new MyInterfaceImpl();

auf

MyInterfaceImpl objektInterface = new MyInterfaceImplZwei();

Habe ich einen Denkfehler?

Schöne Grüße aus Rheinland,

Eure Ratna

 

[Daassan]

also der grundgedanke eines Interfaces ist
dass man eine einheitliche Schnittstelle hat.
die konkrete implementierung ist, letztlich vollkommen egal, solange die signatur stimmt.

Das hat den Vorteil, das du "variable" Verarbeitungen schreiben kannst.
Anstatt immer genau die Klasse zu nennen, gibst in den Paras nur das interface an.
Damit kannst du alle beliebigen Implementierungen an der Stelle übergeben.

bsp währe bei dem Thema Threads das interface Runnable.
methode ist void run();

was in dem Thread berechnen und verarbeitet werden soll wird von fall zu fall implementiert
aber dem Thread ist es ja egal da alle objekte die es bekommt mindestens diese methode haben muss

wenn du aber die objektklasse wissen willst geht das insofern ich mich nicht irre mit dem .class attribut
aber wenn du das wissen musst nützt das interface nichts mehr ^^

 

[ratnalein]

Hallo zusammen,

vielen Dank für die Hilfestellungen. Ich habe soweit verstanden:
Mit dem Interface als Datentyp, kann quasi viel mehr reinkommen als irgendwie den Datentyp einzuschränken.

Aber folgendes:

List myList = new ArrayList(); // programming to the List interface

instead of

ArrayList myList = new ArrayList(); // this is bad
These look exactly the same in a short program, but if you go on to use myList 100 times in your program you can start to see a difference. The first declaration ensures that you only call methods on myList that are defined by the List interface (so no ArrayList specific methods). If you've programmed to the interface this way, later on you can decide that you really need

List myList = new TreeList();
and you only have to change your code in that one spot. You already know that the rest of your code doesn't do anything that will be broken by changing the implementation because you programmed to the interface

Leider verstehe ich noch nicht, wie der Punkt mit "Implementierungen ganz leicht austauschen" gemeint ist.

Wenn ich doch eine Klasse erstelle, die ein Interface implementiert, dann habe ich ja die Methoden aus dem Interface in der "echten" Klasse zu definieren. Für jede Klasse, die das Interface implementiert, muss ich die Interface-Methoden defnieren. Wo ist hier der Punkt "Implementierungen austauschen"?

Spinne ich eigentlich?

Vielen Dank.

Schöne Grüße aus Rheinland,

Eure Ratna

 

[Timothy Truckle]

Leider verstehe ich noch nicht, wie der Punkt mit "Implementierungen ganz leicht austauschen" gemeint ist.

Wenn ich doch eine Klasse erstelle, die ein Interface implementiert, dann habe ich ja die Methoden aus dem Interface in der "echten" Klasse zu definieren. Für jede Klasse, die das Interface implementiert, muss ich die Interface-Methoden defnieren. Wo ist hier der Punkt "Implementierungen austauschen"?

Schau doch mal in die API zu [JAPI]java.util.List[/JAPI] und da den Punkt "all known impementations".

Wenn Du also eine Referenz vom Typ [JAPI]List[/JAPI] definierts kannst Du dem alle diese "known impementations" und auch alle "unknown impementations" (z.B. Zukünftige) zuweisen.

Wenn deine Referenz vom Typ [JAPI]ArrayList[/JAPI] ist müssen alle Objekte, die du dieser Referenz zuweisen willst [JAPI]ArrayList[/JAPI] erweitern.

innerhalb einer Methode ist das vielleicht gar nicht so interessant, aber für Parameter und Rückgabewerte kann das viel Arbeit ersparen, wenn man deren Typ möglichst weit "unten" in der Vererbungshirarchie ansiedelt, und Interfaces sind da eine gute Wahl.

bye
TT

 

[ratnalein]

Hallo zusammen,

@Timothy Truckle, danke.. Der einzige Vorteil bei so einer Konstellation sehe ich lediglich darin, dass man ALLES als Parameter übergeben kann, hauptsache implementiert dieses ALLES das Interface.

Nein, es geht mir wirklich um die Begründung, warum man folgendes bevorzugen soll:

List myList = new ArrayList();

statt:

ArrayList myList = new ArrayList();

Im Beitrag Nr. 6 ist eine Begründung, die ich leider nicht verstehen. Ich verstehe, dass bei ArrayList myList = new ArrayList() die Variable myList nicht mehr frei "zu bewegen" ist, sie kann lediglich auf ein Objekt vom Typ ArrayList referenzieren. Hingegen kann bei der Variante List myList = new ArrayList() die Variable List auf "alles" referenziert werden, hauptsache dieses "Alles" das Interface List implementiert.

Weiter in der Begründung steht, dass man nur "einmal den Code umändern muss". Ich kann mir hierbei leider nicht mehr helfen. Och je, ich hoffe, meine Frage ist verständlich. Vielen Dank.

Schöne Grüße aus Rheinland,

Eure Ratna

 

[Timothy Truckle]

Weiter in der Begründung steht, dass man nur "einmal den Code umändern muss". Ich kann mir hierbei leider nicht mehr helfen.

Ich kanns nur wiederholen: solange Du dich innerhalb einer Methode bewegst gibt es erst mal keinen essenziellen Vorteil. Hier geht es lediglich darum, sich das Programmieren gegen Interfaces anzugewöhen.

Wichtig wird das, sobald man Parameter und Rückgabewerte definiert. Und hier beginnt dann das Problem:
Viele IDE's kennen ein automatischen Refactoreing "extract method". Dabei kann man einige Zeilen Markieren und die IDE verschiebt diese in eine neue Methode, die man dann nur noch benennen muss. Die Typen der Parameter und des Rückgabewertes bestimmt sie anhand der Typen der Referenzen, die bei dieser Aktion beteiligt sind. Wenn also die Referenz vom konkreten Typ ist, ist es auch der Parameter/Rückgabewert.
Dazu kommt, dass es in Java guter Stil ist, auf diese Weise viele kleine Methoden zu erzeugen.
Und das kann richtig blöd werden, wenn man später feststellt, dass eine LinkedList wohl doch besser gepasst hätte und man nun 6/7 Methoden anpassen muss.


bye
TT

 

[ratnalein]

Hallo Timothy,

ich glaube, ich habe so langsam aber sicher verstanden.

List myList = new ArrayList(); // programming to the List interface

instead of

ArrayList myList = new ArrayList(); // this is bad
These look exactly the same in a short program, but if you go on to use myList 100 times in your program you can start to see a difference. The first declaration ensures that you only call methods on myList that are defined by the List interface (so no ArrayList specific methods). If you've programmed to the interface this way, later on you can decide that you really need

List myList = new TreeList();
and you only have to change your code in that one spot. You already know that the rest of your code doesn't do anything that will be broken by changing the implementation because you programmed to the interface

The first declaration ensures that you only call methods on myList that are defined by the List interface (so no ArrayList specific methods)

--> die Referenzvariable kann also lediglich Methoden implementieren bzw. aufrufen, die von dem Interface angeboten werden(z.B. add, clear, equals, usw...).

later on you can decide that you really need
List myList = new TreeList();
and you only have to change your code in that one spot.

--> die obige Aussage stimmt, ABER nur unter den Prämissen, dass man im GESAMTEN Code lediglich Methoden implementieren bzw. definieren, die lediglich vom Interface List angeboten werden


Und zwar das Ganze vielleicht aus der Erkenntnis, dass die eine oder andere Methode vom Interface List bei verschiedenen IMPLEMENTIERENDEN Klassen bzw. Objekten unterschiedliche Laufzeit haben. Zum Beispiel, TreeList braucht irgendwie viel schneller als ArrayList bei der Methode clear. Deswegen ändert frau ja um von:
List myList = new ArrayList();

auf

List myList = new TreeList();

Wenn es richtig ist, was ich hier oben gesagt habe, dann sehe ich einen ganz großen Nachteil bei diesem Programmierstill:
Frau ist "gezwungen", lediglich die Methoden von List implementieren bzw. definieren bzw. aufrufen zu dürfen.

Stimmt das????:L

Vielen lieben Dank

Schöne Grüße aus Rheinland,

Eure Ratna

 

[Daassan]

List is nen gutes beispiel
es gibt viele Frameworks die Listen implementiert haben als wiedergaben

bestes beispiel ist hier zB jaxb, jpa, rmi...

jaxb zb wird genutzt um XML-Inhalte als Objekte zu binden.

sowas kommt oft vor:
[XML]<mails>
<mail>f@b.de</mail>
<mail>y@b.de</mail>
<mail>i@b.de</mail>
<mails>[/XML]

um das zu übersetzen werden Listen genutzt.
es ist aber die Entscheidung des Anwenders des Frameworks welche liste er nutzt,
denn es wird bei der Deklaration nur List als interface angegeben ->
es kann eine dieser sein: ArrayList, AttributeList, CopyOnWriteArrayList, LinkedList, RoleList, RoleUnresolvedList, Stack, Vector
da alle durch das Interface die gleichen Methoden besitzen MUSS

welche verwendet wird ist nun unabhängig und variable vom Framework aus
und du als nutzer des FW bist nicht gezwungen eine ArrayList zu nutzen


ps. soweit ja du hast recht, wenn du ein interface als deklaration nutzt kannst du nur auf die darin definierten funktionen zugreifen.
die implementierung hat dann jedoch nichts mehr damit zu tun, so kommt es zu den laufzeit unterschieden wie dein clear
das jeweilige letztlich genutzt objekt kann jedoch tolle andere funktionen noch besitzen die im interface nicht vorhanden sind ergo für dich unbekannt
--> darum musst du genau wissen was du zum schluß nutzt
das List interface besitzt alle nötigen funktionen die man braucht um ne bestimmte Liste zu nutzen
hinzufügen löschen leeren ..... usw. wenn es dir reicht bleib bei list dann ist es variabler du kannst einfacher eine mehrzahl an objekte austauschen und verarbeiten
benötigst du aber wirklich bestimmte funktionen dann musst du gezwungener maßen eine spezielle implementation nutzen und kannst nicht mehr einfach tauschen

 

[ratnalein]

Hallo Daassan,

danke für die Info.. was in meinem vorigen Beitrag steht, stimmt aber oder?
Ich meine, man kann natürlich z.B. folgendes definieren:

public class eigeneListe implements List{
     clear(){
         // tue was
         // Diese Methode stammt aus List
        }

     eigeneMethode(){
        // tue was        
        // tue was
        }
}

... void methode...
List meineListe = new TreeList();
meineListe.clear();
meineListe.eigeneMethode(); //hier meckert der Compiler, da es eigeneMethode() in TreeList nicht gibt.

Hingegen funktioniert folgendes:

... void methode...
List meineListe = new eigeneListe();
meineListe.clear();
meineListe.eigeneMethode();

Das heißt, sobald man eigeneMethode() braucht, muss meineListe ein Objekt von eigeneList referenzieren. Also, für diesen KLEINEN Anwendungsfall gibt es scheinbar keinen Vorteil, ob man:

List meineListe = new TreeList();
oder
eigeneListe meineListe = new TreeList();

verwendet. Denn, so oder so muss umgeändert werden, sobald meineListe die Methode eigeneMethode() aufrufen will.

Stimmt es soweit?

Ich gehe davon aus, dass es wirklich Anwendungskonstellationen gibt, bei denen die Variante
List meineListe = new TreeList();
Vorteile bringt.

Ist diese Annahme richtig?

Vielen Dank.

Schöne Grüße aus Rheinland,

Eure Ratna

 

[Spacerat]

Mal was anderes... ist irgendjemandem Aufgefallen, dass das Engangbeispiel des TO nich wirklich sinnvoll ist? Evtl. ists ja deswegen auch mehr oder weninger unverständlich...
So würde es Sinn ergeben... (Mit anderen Worten: Ja, deine Annahme ist richtig.)
[Java]interface Greeting {
public void sayHello();
}

class GermanGreeting implements Greeting {
public void sayHello() {
System.out.println("Hallo");
}
}

class EnglishGreeting implements Greeting {
public void sayHello() {
System.out.println("Hello");
}
}[/code]Jetzt sei nur das Interface bekannt und evtl. noch eine Factory dafür.

class GreetFactory {
  public static Greeting getGreeting(Locale locale) {
    String loc = locale.toString().toUpperCase();
    if(loc.contains("DE") {
      return new GermanGreeting();
    }
    return new EnglishGreeting();
  }

  public static void main(String[] args) {
    Greeting gr = GreetFactory.getGreeting(Locale.getDefault());
    gr.sayHello();
  }
}

 

[ratnalein]

Hallo zusammen,

@Spacerat
super, danke.. :toll:ich hab deinen Code mir angeschaut, mal eine Anwendung, wo die Referenzvariable (gr) mit Datentyp aus Interface auch "gut" sein kann. Und das tolle ist, ich habe den Code verstanden. :idea: Ich bin jetzt glücklich.

Vielen Dank.

Schöne Grüße aus Rheinland,

Eure Ratna

 

[Spacerat]

...mal eine Anwendung, wo die Referenzvariable (gr) mit Datentyp aus Interface auch "gut" sein kann...

Mal ist gut... Gewöhn's dir an noch viel besser... Es gibt unzählig viele Bereiche, wo Interfaces geeignet sind. Schlimmer noch, es gibt sogar Bereiche, wo man besser von Anfang an Interfaces verwendet haben sollte (z.B. AWT und Abkömmlinge).

 

[TheDarkRose]

verwendet. Denn, so oder so muss umgeändert werden, sobald meineListe die Methode eigeneMethode() aufrufen will.

Schlechtes Beispiel. Wenn du weißt du brauchst eine spezielle Methode, die das Interface nicht hat, nimmt man auch die Implementierung. Spezielle Liste, etc.

Kommt man aber mit den Standardmethoden von List aus, sollte man auch immer nur gegen das Interface programmieren. Besonders wenn man die Verwendung in Methodenparametern und Rückgabewerte beachtet. Denn sollte man den Listentyp ändern wollen (wegen Performance oder anderen), dann muss man bei entwickeln gegen das Interface nur bei der Initialisierung den Typ umschreiben.
Hat man dies aber nicht gemacht und in sage mal 100 Methoden z.B. ArrayList verwenden, viel Spaß beim umschreiben. Oder sicherstellen, das keine Methoden verwendet wurden, die es nicht in der anderen Liste gibt.

 

[ratnalein]

mach mich nicht schwach.. och jee.. weiss nicht ob Informatik noch der richtige Studiengang ist, wenn ich bei dieser Thematik schon Problem habe;(

mhh.. ich weiss nicht, ob es zu viel verlangt ist, könntest Du dir vielleicht ein Beispil ausdenken, wo ein kleines Umändern von zum Beispiel:

Greeting gr = new GermanGreeting();

auf

Greeting gr = new EnglishGreeting();

gut ist?


Weil, laut:

List myList = new ArrayList(); // programming to the List interface

instead of

ArrayList myList = new ArrayList(); // this is bad
These look exactly the same in a short program, but if you go on to use myList 100 times in your program you can start to see a difference. The first declaration ensures that you only call methods on myList that are defined by the List interface (so no ArrayList specific methods). If you've programmed to the interface this way, later on you can decide that you really need

List myList = new TreeList();
and you only have to change your code in that one spot. You already know that the rest of your code doesn't do anything that will be broken by changing the implementation because you programmed to the interface

muss es eigentlich so ein Beispiel geben. Aber wenn es Dir dazu nichts einfällt, ist kein Problem. Es ist wahrscheinlich zu viel verlangt.

Schönen Dank.

Schöne Grüße aus Rheinland,

Eure Ratna

 

[TheDarkRose]

Dir kann es im restlichen Programm egal sein, welches Greeting verwendet wird. Somit kannst du die Sprache an einer einzigen Stelle ändern. Schöner ist es eben noch mit der Factory von Spacerat. OOP halt ^^

 

[Spacerat]

Versuch' mal "<SortedSet<Object>>.higher(Object current)"... oder nee, vergiss es, das wird eh' nichts. Und jetzt stell dir vor, du hättest in 1000 Programmzeilen diese spezielle TreeSet-Methode verwendet und TreeSet erfüllt nun plötzlich die Vorraussetzungen nicht mehr (warum auch immer), weswegen sie durch ein anderes SortedSet ausgetauscht werden muss.