Extend, Implement, Abstract

[Rouven]

Hello,

• Was macht nun das Interface InterfaceB nun genau. Ist es nun einfach ein Interface in der die Methoden von ClassB und ClassBWebservice drin stehen, die dann für ClassA vorgeschrieben werden oder läuft dies anders ab. Das erstere wüde wohl wenig sinn machen, wenn ich in ClassA alle Methoden implementieren muss, die mir das Interface vorschreibt.

Ja, es ist einfach nur ein Interface (in Deutsch: Schnittstelle). Dein Klassendiagramm zeigt den Zweck ganz deutlich: Du hast ein A, das etwas verwenden möchte. Es möchte eine Methode getDataFromB aufrufen, die ihm irgendwas liefert. Dem A ist aber vollkommen egal, ob das jetzt ClassB oder ClassBWebservices ist, es arbeitet einfach stur gegen das Interface.
Wenn du am Anfang der Java-Welt stehst, dann stellt sich dir vielleicht die Frage "wie geht das, A muss doch irgendwas erzeugen", du denkst vielleicht dran, dass im Code von A irgendwo steht
   InterfaceB meinB = new ClassB();
oder eben
   InterfaceB meinB = new ClassBWebservices();

Dem ist aber bei "entkoppelter" Programmierung nicht so. Nein, viel eher steht irgendwo ein Aufruf "Hallo, kann mir mal irgendjemand ein InterfaceB besorgen" - dieser irgendjemand hat Kriterien, nach denen er auswählt, ob er sich für B oder BWebservice entscheidet, die dem A aber vollkommen verborgen bleiben.

Tragen wir es auf eine etwas andere Ebene und nehmen ein Beispiel:
A sei Teil eines Web Content Management Systems, es hält einen Inhalt in der Hand, den es gerne zum Nutzer schicken möchte.
Es gibt ein Interface ContentRenderer, das eine Methode render(Content) zur Verfügung stellt.
Abhängig davon, ob dein Benutzer ein iPhone oder ein ausgewachsenes PC-System vor sich hat, möchtest du jetzt den Inhalt unterschiedlich aufbereiten. WAS für ein System du vor dir hast, weißt du aber völlig wo anders, sagen wir in einer Klasse UserProfile, da hast du die Daten mal ausgewertet und hältst die jetzt vor. Jetzt passiert folgendes:
(1) A hat den Inhalt den es verschicken möchte, weiß aber nicht was das für ein Benutzer ist
(2) A lässt sich von UserProfile einen adäquaten ContentRenderer geben, z.B. ContentRenderer myRenderer = UserProfile.getRendererForUser();
(3) A kann, ohne zu wissen, ob es jetzt einen IPhoneContentRender oder einen PCContentRenderer vor sich hat, blind die Methode render(myContent) aufrufen, da diese vom Interface gestellt wird.

A wird also ausschließlich gegen das Interface entwickelt. Das hat noch einen weiteren Vorteil - sagen wir, Googles Android kriegt in Zukunft den Inhalt nochmal anders aufbereitet - am Ablauf von A ändert das mal gar nichts, der möchte weiterhin nur den Inhalt rausspucken - wäre jetzt ziemlich blöd, wenn du den Code anpassen müsstet, nur weil es plötzlich auch noch einen AndroidRenderer gibt - passiert dir beim Schreiben gegen das Interface nicht, da kümmert sich ausschließlich UserProfile drum.

Genau solche Entkopplungsszenarien sind ein Grund für Interfaces.

MfG
Rouven