Abstrakte Klassen und Interfaces

[A3XX]

HI

Bin mich gerade wieder bisschen tiefer am in Java reinlesen, aber ich kapiere nicht für was abstrakte Klassen und Interfaces genau gebraucht werden können? So wie das in meinem Buch beschrieben ist kriegt man den Eindruck, dass es schlauer wäre die jeweiligen Methoden nicht zu implementieren (beim Inteface) sondern direkt reinzuschreiben. Denn was der Autor in das Intefarce geschrieben hat sind nur die Namen der Methoden...

 

[Illuvatar]

HI
Bin mich gerade wieder bisschen tiefer am in Java reinlesen, aber ich kapiere nicht für was abstrakte Klassen und Interfaces genau gebraucht werden können?

Hä? Was meinst du mit dem Satz? Alle abstrakte Klassen/Interfaces können gebraucht werden bzw. haben einen Nuzten, sonst häte sie ja niemand geschrieben, oder?
Edit: Lesefehler, hab gelesen "was für" statt "für was" :wink:

So wie das in meinem Buch beschrieben ist kriegt man den Eindruck, dass es schlauer wäre die jeweiligen Methoden nicht zu implementieren (beim Inteface) sondern direkt reinzuschreiben. Denn was der Autor in das Intefarce geschrieben hat sind nur die Namen der Methoden...

Du musst die Methoden implementieren und das bedeutet direkt reinschreiben, oder was meinste?

 

[A3XX]

Ne, in dem Buch, das ich lese steht immer:

public interface test {
methodea();
methodeb();
}

public class test2 implements test {
methodea() {
//eigentlicher Inhalt
}
}

Sorry, sehr spartanisch dargestellt, vorallem sicher vollkommen falsch geschrieben. Aber eben, in dem Interface hat der Autor eigentlich nur die Namen erwähnt und dort, wo sie dann implementiert werden, erst den Code hinzugefügt. Ich kapier nicht was das füre inen Nutzen haben soll?! Und abstrakte Klassen verstehe ich sowieso nicht. Gibt es irgendwo was gutes & verständliches zum Nachlesen über die beiden`? Nicht www.javabuch.de --- das ist genau das verwirrende Buch...

 

[Isaac]

Manchmal ist es schlauer gegen ein Interface zu programmieren.

Das hat den Vorteil das man bei der Instanziierung das Interface angeben kann.

Also z.b.

List myList = new Vector(); 
List myList2 = new ArrayList();

Das ist an sich ja noch nicht spannend. Wirklich fuchsig wird die Sache aber nun wenn ich eine Methode schreibe

public void(List list)
{
    //mach was tolles mit der Liste
}

Da ich nicht gegen Vecotr oder ArrayList, sondern gegen das List Interface programmiert habe ist es vollkommen egal was du für ein Objekt da rein steckst solange es das List Interface implementiert.


abstract Klassen haben den Vorteil das sie nicht instanziiert werden können sondern das man nur von ihnen ableiten kann. Methoden die keinen Body besitzen müssen vom Programmierer gefüllt werden. Wenn ich also nicht weiss wie die Implementierung sein soll zwinge ich den Benutzer der Klasse eine Methode zu implementieren.

 

[Roar]

jaja das böse alte javabuch...
interfaces sind zur typendeklaration da. Das heisst du schreibst ein interface und deklarierst bestimmte methoden. dann ist jede implementierende Klasse ein Typ vom interface. In einer anderen Klasse/Methode kannst du dann z.B. eine instanz einer klasse die ein bestimmtes interface imnplementiert erwarten, und dieses dann weiterverabreiten.

so z.B.

public interface Plugable {
public String getName();
}

class EinPlugin implements Plugable {

public String getName() { return "Ein Plugin"; }
}

class EinAnderesPlugin implements Plugable {

public String getName() { return "Ein anderes Plugin"; }
}

class BlahBlahBlah {
public static void main(String[] args) {
PluginVerarbeiter.liesName(new EinPlugin());
PluginVerarbeiter.liesName(new EinAnderesPlugin());
}
}

public class PluginVerarbeiter {

public static void liesName(Plugable p) {
System.out.println("Name: "+ p.getName());
}
}

 

[Illuvatar]

In dem Buch sind garantiert nirgends Klassenname klein geschrieben.
Und dank dem Buch hab ichs verstanden. Da is doch z.B. ein sehr schönes Beispiel.

Ein interface Groesse:

/* Groesse.java */

public interface Groesse
{
  public int laenge();
  public int hoehe();
  public int breite();
}

Und eine Klasse, die Groeße implementiert, d.h., man kann von ihr die Groeße erfahren:

/* Auto2.java */

public class Auto2
implements Groesse
{
  public String name;
  public int    erstzulassung;
  public int    leistung;
  public int    laenge;
  public int    hoehe;
  public int    breite;

  public int laenge()
  {
    return this.laenge;
  }

  public int hoehe()
  {
    return this.hoehe;
  }

  public int breite()
  {
    return this.breite;
  }
}

(Da fehlen halt setter-Methoden)

Genauso diese Klasse:

public class FussballPlatz
implements Groesse
{
  public int laenge()
  {
    return 105000;
  }

  public int hoehe()
  {
    return 0;
  }

  public int breite()
  {
    return 70000;
  }
}

Auch hier kann man die Größe erfahren.

Beide Klassen beschreiben unterschiedliche Dinge, könnten aus unterschiedlichen Klassen abgeleitet sein.
Dennoch haben beide eine Groesse, das wird durch das Interface angezeigt.
Du könntest ein Groesse[] haben, du weißt nicht, was es für Klasen sind, kannst aber die Größe erfahren.

Edit: Zweiter

 

[A3XX]

Tönt beides extrem komplex. Verwendet ihr das viel? Und gibt es noch eine etwas längere Erklärung irgendwo zum Nachlesen?

 

[Illuvatar]

Ich verwende es vor allem bei Listeners. Die kommen aber erst Kapitel 28 .

interface EventListener
{
    public void event(Event e);
}

Die können sich wo registrieren, werden da in einem Vector gespeichert und können ganz einfach aufgerufen werden.

 

[Isaac]

Das ist überhaubt nicht kompliziert. Immer wenn du eine gemeinsame Basis schaffen willst für verschiedenste Objekte nutzt du Interfaces. Wenn du dir mein Posting anschaust wird der Vorteil, hoffe ich, klar. ArrayList und Vector könne unterschiedlichste Vorfahren haben, sie müssen nicht mal ein gemeinsames Urobjekt habe und trotzdem kann man sie nun auf die gleiche Art und Weise behandeln. Statt 2 Methoden brauche ich nur noch eine, die sich auf dem Interface abstützt.



Ein Beispiel:

Es gibt Tools die für dich das Sortieren übernehmen. Wer will schon immer wieder ein Bubblesort neu implementieren?
Nun hast du also eine Sammlung von Objekten die in einem Vector oder was weiss ich wo drin sind. Aber woher weiss das Tool wie er deine ganz eigenen privaten Objekte sortieren soll?

Hier kommt das Interface "Comparable" ins Spiel. Du implementierst nun in deine Klasse von der die Objekte erzeugt worden sind das Interface "Comparable". Dieses Interface zwingt dich nun die Methode "compareTo" zu implementieren. Das must du natürlich selber machen da nur du selbst weisst wie welches deiner Objekte im vergleich zu einem anderen der selben Art "grösser" oder "kleiner" ist. Sei es nun Lexikalisch an einem String oder einer int member variable im Objekte, its up to you.

Aber, dank dem Interface kannst du nun alle Methoden nutzen die ein Objekt mit Compareable Interface erwarten. Denn diese Methoden stüzten sich intern ausschliesslich auf den Methoden ab die im Interface definiert sind.

 

[bygones]

ah menno Isaac - das ist mein lieblingsbeispiel für ein Interface.... das wollte ich sagen.... :?

naja - dann mein lieblingsbsp für eine absktrakte Klasse.

Wie bekannt ist gibt es zwei Arten von Menschen - Mann & Frau. Beide haben vieles gemeinsam aber auch vieles (vieles) unterschiedlich... Um das gemeinsame nicht mehrfach zu schreiben denkt man sich eine schöne Vererbungshierarchie aus mit der Klasse Mensch als Oberklasse und die beiden Klasse Mann und Frau erben von dieser Klasse.

Nun willst du aber zwingen, dass ein Mensch entweder eine Frau oder ein Mann ist, es darf kein geschlechtsneutrales Wesen geben. Also machst du die Klasse Mensch abstrakt - d.h. es kann keine Instanz der Klasse Mensch erstellt werden, aber dennoch genießen die beiden unterklassen die Vererbungsidee....

Das ist nur ein Bsp für eine abstrakte Klasse....

 

[A3XX]

Hi again

Danke wieder für eure Antworten. Also das abstrakte ist mir klar, die interfaces so halbwegs, weil ich eben z.B. Bubblesort überhaupt nicht kenne. Aber grob grob ist es klar. Wird mir hoffentlich in irgendnem Tutorial nochmal begegnen damit ich es live kapieren kann

EDIT:

Also nur zur Info, ich hab schone in ganzes Lehrbuch ("Java for Students") durch Ich repetiere jetzt nur nochmal alles mittles diesem anderen Online-Buch, dieses ist aber an gewissen Stellene infach ausführlicher. Sicher ein Grund weil es mehr Nachschlagewerk als Lehrbuch ist. Das andere war sicher das beste Lehrbuch, das ich je in den Händen hielt

 

[Heiko]

ah menno Isaac - das ist mein lieblingsbeispiel für ein Interface.... das wollte ich sagen.... :?

naja - dann mein lieblingsbsp für eine absktrakte Klasse.

Wie bekannt ist gibt es zwei Arten von Menschen - Mann & Frau. Beide haben vieles gemeinsam aber auch vieles (vieles) unterschiedlich... Um das gemeinsame nicht mehrfach zu schreiben denkt man sich eine schöne Vererbungshierarchie aus mit der Klasse Mensch als Oberklasse und die beiden Klasse Mann und Frau erben von dieser Klasse.

Nun willst du aber zwingen, dass ein Mensch entweder eine Frau oder ein Mann ist, es darf kein geschlechtsneutrales Wesen geben. Also machst du die Klasse Mensch abstrakt - d.h. es kann keine Instanz der Klasse Mensch erstellt werden, aber dennoch genießen die beiden unterklassen die Vererbungsidee....

Das ist nur ein Bsp für eine abstrakte Klasse....

Das Beispiel muss ich mir merken, finde ich gut so hat uns das damals keiner erklärt. Wir haben das an PKWs und dann die Automarken erklärt bekommen. ;-)