[Java] Interface - wozu?

[moorhahn]

wozu sind interfaces in java? die theoretische beschreibung is schon klar, in den meisten tutorials oder büchern steht in etwa, dass interfaces dazu da sind, um etwas ähnliches wie die merhfachvererbung (die es in java ja nicht gibt) in java zu verfügung zu haben. denn ohne merhfachvererbung müsste man ja in manchen fällen gleichen code doppelt schreiben, und das würde quasi gegen eine konvention verstoßen und wäre ja auch völlig dämlich, man müsste ja dann bei einer änderung jede methode ändern.
aber wie soll dieses problem durch interfaces beseitigt werden (was ja laut büchern und tutorials der sinn von interfaces wäre), wenn man die methoden sowieso in jeder klasse wieder neu implementieren muss.

von http://java.programmersbase.net/ folgendes beispiel:

interface MyInterface1
{	
  public void print1();
}
interface MyInterface2 extends MyInterface1
{	
  public void print2();
}

class MySuperClass
{		
  protected String s = "ProgrammersBase.NET";
}

class MySubClass extends MySuperClass
implements MyInterface2
{
  public void print1()
  {
    System.out.println(s);
  }
  public void print2()
  {
    System.out.println("ProgrammersBase.DE");
  }
}

public class MyClass
{
  public static void main(String[] args)
  {  	
    MySubClass object = new MySubClass();
    
    object.print1();
    object.print2();
  }
}

dieses beispiel könnte man genauso gut ohne interfaces schreiben.

wozu also dann diese interfaces?

[käptn]

Original geschrieben von moorhahn
dieses beispiel könnte man genauso gut ohne interfaces schreiben.

wozu also dann diese interfaces?

Für mich sind Interfaces eine Art Vertrag, dass ein Klasse eine gewisse Funktionalität implementiert.

~

[moorhahn]

weiß ned wirklich was du damit meinst, hört sich aber in etwa so an, als seien interfaces programmiertechnisch eigentlich sinnlos.

[Seidl]

Mit einem Interface definierst du eine Art Grundfunktionalität die eine Klasse zur Verfügung stellen muss, wenn sie das Interface implementieren will. Auf diese Art könntest du zum Beispiel ein Frontend für ein Programm schreiben ohne selbst wirklich auf die Hintergrunddetails einzugehen. Das Implementieren dieses Teils überlässt du einem Kollegen der eine Klasse schreibt, die das von dir definierte Interface implementiert. Nachdem dein Programm dann ein Jahr lang gelaufen ist kommst du dahinter, dass dein Kollege ein sogenannter Vollnubbler war und das Programm Fehler aufweist. Als Ausweg schreibst du einfach wieder eine neue Klasse die dein Interface implementiert und hängst sie hinter dein Frontend. Problem gelöst.
Man muss sich immer vor Augen halten, dass der Einzelkämpfer-Programmierer nicht unbedingt die Regel ist. In einem Team machen viele Sachen Sinn die für einen allein absolut sinnlos scheinen.


Seit meiner Ausbildung muss ich mich leider grösstenteils als Wald- und Wiesen-Programmierer betätigen und habe nur selten Gelegenheit mit anderen Leuten zu arbeiten die Ahnung vom Programmieren haben. Aus diesem Grund würde ich auf die Korrektheit meiner Erklärung kein Geld verwetten aber ich bin mir recht sicher, dass ich den Kern so ziemlich getroffen habe.

[K@sperl]

Ein Interface zeigt nichts anderes als die Methoder einer Klasse, sehe ich das richtig?

[kju]

Original geschrieben von moorhahn
weiß ned wirklich was du damit meinst, hört sich aber in etwa so an, als seien interfaces programmiertechnisch eigentlich sinnlos.

nein im gegenteil interfaces werden in java sehr häufig verwendet und spielen daher eine wichtige rolle! z.b.: beim Eventhandling (EventListener, ActionListener, KeyListener,
MouseListener, MouseMotionListener, usw.) oder Objektserialisierung (Serializable) ...

[moorhahn]

ja, klar sie sind anscheinend wichtig, aber wie bei obigem beispiel ersichtlich, könnte mans genausogut ohne interface machen.

@seidl: ein interface hat also nix damit zu tun, die in java nicht mögliche mehrfachvererbung zu ersetzen?

[käptn]

Stell dir vor du schreibst ein Programm.

Stell dir vor andere sollen dafür PlugIns schreiben können.

Nun stellst du ihnen ein Interface zur verfügung, das die anderen implementieren müssen.

public interface IPlugin {
    PluginStatus status {
        get {}
    }
    void start();
    void stop();
}

Das ist zwar C#, kann aber nicht soviel Unterschied zu Java sein.

Damit kannst du überprüfen, ob ein Plugin das Interface implementiert und die entsprechenden Methoden/Eigenschaften bietet.

~

[Tarjan]

Also die Erklärung von Seidl ist schon sehr gut. Nur etwas auf unterschiedliche Programmierer ausgerichtet .

Interface ist eben eine Schnittstelle. Die tatsächliche Implementierung erfolgt dann in den Klassen die die Schnitstelle implementieren. Wird mit der Schnittstelle gearbeitet, so interessiert die tasächliche Implementierung nicht, nur das Interface.

Beispiel aus meinen Projekt: Alle Datenbankzugriffe sind in Interfaces gekapselt. Die stellen die Methoden und werden von Factories zurückgeliefert. Die tasächliche Implementierung der Funktionalität, in meinen Beispiel für die DB2 Datenbank sind in Klassen, die die Interfaces implementieren. Soll das ganze jetzt zB. mit Oracle auch funktionieren, so werden einfach neue Klassen geschrieben, die eben die Oraclefunktionalität implementieren. Die Factories liefern dann diese zurück. Der Programmierer der die Datenbankinterfaces verwendet merkt davon überhaupt nichts, da er ja mit den Interfaces arbeitet und ihn die Implementierung für welche Datenbank auch immer nicht interessiert.

Das lässt sich natürlich auf jeden Bereich anwenden.

[Who-T]

Anderes beispiel:

du hast eine ArrayList, die du durchlaufen willst.

ArrayList al = new ArrayList();
// fill arraylist with data
Iterator it = al.iterator();

was du jetzt hast ist ein iterator. und wenn du dir die api-doc ansiehst kommst du drauf dass Iterator ein interface ist.

was heißt das jetzt für dich?

du weißt dass du eine instanz einer bestimmten klasse bekommen hast (weil instanzen von interfaces gibt es nicht).
allerdings weißt du nicht was für eine klasse - aber, und das ist das entscheidende für dich - es kann dir wurscht sein weil du weißt, dass diese klasse alle methoden des interfaces Iterator implementiert hat. wie - das kann dir auch wieder wurscht sein.

wenn du iterator() an einer anderen collection aufrufst, kriegst du eine instanz einer womöglich ganz anderen klasse zurück. aber du kannst mit den in Iterator definierten methoden wieder durch deine collection laufen.

genau darum gehts - ein anderer programmiert was für dich, wie er das macht interessiert dich nicht, hauptsache er gibt dir eine standardisierte schnittstelle über die du zugreifen kannst.