Hi,

meine erste Frage ist, ich habe folgende interface-Klasse:

public interface VersicherungI
{
     public double berechnePraemie(double Versicherungssumme);
}
 

Was für einen Sinn hat das? Da ist ja kein Rumpf definiert?

2. Frage wäre, was der Unterschied zu Vererbung genau ist.

Danke schonmal.

p-flash

[Ben]

zunächst einmal möchte ich darauf hinweisen, dass du einen formulierungsfehler gemacht hast. es gibt keine "interface-klasse". entweder es ist eine klasse oder es ist ein interface

du hast ein interface. in interfaces stehen nur die signaturen der methode, also das gerüst, der kopf .. wie du es auch nennen willst

wenn du nun das interface implementierst ( implements ), dann musst du alle methoden, die in dem interface angegeben wurden implementieren .. (komischer satz -)
naja. es heißt also, dass du z.b. in diesem beispiel hier:

public interface TestInterface
{
       public void machWas( String text );
}
 
 
public class Demo implements TestInterface
{
        public void machWas( String text )
        {
               // irgendwelcher code
        }
}
 

die methode machWas( String text ) ausimplementieren MUSST. das ist eine pflicht. auf so etwas trifft man z.b. früh bei dem Interface "ActionListener" und der Methode "acitonPerformed( ActionEvent event ).
falls dir das nichts sagt .. vergiss es

eine klasse kann beliebig viele interface einbinden ... aber nur von einer klasse erben. das ist ein unterschied zu z.b. C++

wenn du nun vererbung hast .... bsp:

class Fahrzeug
{
        public void machGeraeusch( String geraeusch )
        {
              System.out.println( geraeusch );
        }
}
 
 
class Auto extends Fahrzeug
{
        public void berechneKosten()
        {
             /* irgendwas berechnen, was speziell für ein auto ist und was ein fahrrad z.b. nicht hat */
        }    
}
 
 
public class Demo
{
     public static void main( String[] args )
     {
             Fahrzeug toefftoeff = null;
             
             // je nach eingabe / auswahl wird nun ein objekt erstellt
            if( irgendwas )
            {
                   toefftoeff = new Auto();
            }
            else
            {
                   toefftoeff = new Lastwagen();
            }
 
            toefftoeff.berechneKosten();
            toefftoeff.machGerausch( "brumm brumm" );
 
     }    
}
 

oder so ähnlich

du könntest jetzt in der klasse Auto z.b die methode machGeraeusch() überschreiben. das musst du aber nicht.

wenn du z.b. so etwas machst

class GrafikDemo extends JFrame
 

dann hast du alle eigenschaften des JFrame zur verfügung, musst sie aber nicht nutzen.

hm. war das verständlich erklärt? irgendwie bezweifle ich das jetzt im nachhinein ^^
naja. danke für das feedback ... bei fragen. raus damit

grüße ben.

Also ich würde sagen ic hhabe es verstanden, wenn die Antwort auf folgende Frage ja ist:

Sind interfaces also dafür, den Programmierer zu "zwingen" gewisse Methoden oder Attribute in sein Prgramm zuzufügen? Oder was habe ich flasch verstanden?

Danke schonmal für die Antwort.

p-flash

[Ben]

hm. so würde ich das jetzt nicht beschreiben. also das problem ist .. ich denke es gibt keine pauschale antwort auf deine frage.
der eine nutzt gerne interfaces, der andere gerne vererbung ein weiterer erbt gerne von adaptern, die ihrerseits ein interface implementieren.

*einschub*
ein adapter ist einfach eine klasse, die alle methoden, die ein interface fordert leer implementiert. also

public void methode()
{
}
 

wenn man dann den adapter erbt muss man nicht mehr alle methoden implementieren. is tricky, wenn man ein interface immer nur zur hälfte braucht


aber bzgl. deiner frage.
ich kann dir das leider nicht so ganz zufriedenstellend beantworten.

ich würde sagen, dass es am programmierstil, der anforderung und der programmstruktur liegt, was am günstigsten ist.

fakt ist aber, dass ..
... mehrfachvererbung nicht möglich ist,
.. mehrere interfaces implementiert werden können
.. ein interface auch erben kann.

durch das bereitstellen von interfaces schaffst du eien schnittstelle. da nur die methodensignatur feststeht, weißt du zwar wie die methode heißt und du solltest aufgrund des namens auch wissen was sie macht ... wie es implementiert ist ist dann aber erst mal nicht interessant.

soweit .. vielleicht hat noch jemand eine bessere erklärung.


grüße ben.

Jo super. Danke für die gute Erklärug. Bin jetzt um einiges schlauer. Unser Professor erklärt es net so doll.

p-flash

[Ben]

hui. danke

na. wie gesagt. ich würde da gerne noch eine erklärung von jemand anderem hören. ist ja schließlich immer besser mehrere meinungen zu haben

grüße ben.


nachtrag:
--------

hier findet man noch eine kurze aussage, die eventuell noch hilfreich ist:

Bemerkenswert ist auch die explizite Unterscheidung von Schnittstellen und Klassen. Eine Klasse kann beliebig viele Schnittstellen implementieren, hat aber stets genau eine Basisklasse. Alle Klassen sind – direkt oder indirekt – von der Wurzelklasse Object abgeleitet.

Quelle: http://de.wikipedia.org/wiki/Java_%2...le_der_Sprache

auch interessant:
Quelle: http://de.wikipedia.org/wiki/Schnitt...grammierung%29

da ist ganz gut beschrieben, was schnittstellen / interfaces so "machen"

Also ... ihr wollt eine weiter Meinung zu dem Thema ...

Interfaces werden oft dazu benutzt Schnittstellen festzulegen.
z.B.
du hast ein Tool programmiert, welches durch hinzufügen von weiteren Klassen von wildfremden Menschen (die deinen originalen Sourcecode nicht kennen !) erweitert werden kann (z.B. ein Editor, der durch Plugins um weitere Funktionalitäten erweitert werden kann). Um die Erweiterungen einbinden zu können müssen die aber bestimmte Bedingungen erfüllen. Machen wir doch mal ein kleines Beispiel:

public interface Plugin {
     public void execute();
}
 

Das soll fürs Interface reichen. d.h. ... jeder der ein Plugin für DEIN Tool schreiben will muss das Interface Plugin implementieren und somit die Methode execute() mit Leben füllen.

public class FremdesPlugin implements Plugin {
     public void execute(){
          // mache irgendwelche Schweinereien
     }
}
 

Dadurch das der Fremdling DEIN Interface implementiert weisst du ganz genau, dass es die Methode execute() dort gibt und du kannst vom Fremden Plugin eine Instance bilden:

try{
     Class c = Class.forName( "FremdesPlugin" );
     Constructor cons = c.getConstructor(null);
     Plugin p = (Plugin)cons.newInstance(null);
     p.execute();
}
catch( Exception e){
     // Fehler fangen
}
 

Jetzt sieht du den Vorteil von Interfaces (auch wenn es etwas unübersichtlich ist) ... Mittels Reflexion holst du dir eine Instance ... die aber immer vom Typ Object ist (damit alleine könnte man nicht viel anfangen). Aber da du weisst, dass die Klasse DEIN Interface implementiert - und somit auch von Typ deines Interfaces ist !!!!!!!! - kannst du das Object auf ein Plugin casten. Und nun kannst du die Methode execute() aufrufen (die MUSS es ja geben !).

War das zu umständlich ??


OK ... dann eben noch ein zweites Beispiel:
Du hast ein Tool welches mit GUI benutzt werden kann ... nun willst du aber (weil es so korrekter ist) die GUI von der Applikation trennen. Aber die GUI muss ja irgendwie an die Daten kommen, die sie anzeigen soll. Nehmen wir mal an, du hast in deiner Applikation eine Adressliste mit vielen tausenden und abertausenden Adressen. Nun willst du nicht jeden einzelnen String vond er Applikation zur GUI transferieren (kann man machen ... aber in unserem Beispiel geht das nicht - warum auch immer ). Deshalb willst du das komplette Adresslisten-Objekt an die GUI reichen ... ist aber eigentlich nicht so toll, da die GUI - die ja von deiner Applikation so wenig wie möglich wissen soll - sonst vollen Zugriff auf das Objekt hat. Nun machst du also ein Interface, welches bestimmte Zugriffsmethoden vorschreibt:

public interface Adresslist {
     public String[] getAllNames();
     public String getAdress( String name );
}
 

... ein wenig konstruiert ... aber als Beispiel solls genügen. Die Applikation implementiert nun dieses Interface in einer Klasse:

public class AppAdresslist implements Adresslist {
     private String[] names,
     private Hashtable adresses;
 
     public String[] getAllNames(){
          return this.names;
     }
 
     public String getAdress( String name ){
          return (String)this.adresses.get( name );
     }
}
 

Nun hast du ja auch noch eine Fassaden-Klasse, die die Verbinsung zwischen Applikation un GUI herstellt geschrieben. Über diese kann die GUI nun sich ein Objekt vom Typ Adresslist holen:

public class Fassade {
     private AppAdresslist list;
 
     public Adresslist getAdresslist(){
          return this.list;
     }
}
 

Im ersten Moment sieht es so aus, als wenn die GUI doch vollen Zugriff auf die Liste hat. Wenn aber genau hinschaut (wie du jetzt gerade) sieht man, das ein Objekt vom Typ Adresslist und nicht AppAdresslist zurückgegeben wird. Nun kann die GUI also nur auf das zugreifen, was im interface definiert worden ist - natürlich vorrausgesetzt, dass die GUI das INterfase kennt -

public GUI {
     private Fassade myFassade = new Fassade();
 
     ...
     Adresslist al = myFassade.getAdresslist();
     String[] allNames = al.getAllNames();
     for( int i=0; i<allNames.length;i++){
          String adr = al.getAdress( allNames[i] );
          ...
     }
}
 

Klar geworden wie das funzt ? Die GUI hat keinen blassen Schimmer, wie die Adressliste aufgebaut ist ... sie weiss nur, dass es die Methoden getAllNames() und getAdress( String name ) gibt ... das ist alles. DAs Einzigste was jetzt noch doof ist ... ein gemeiner GUI-Programmierer könnte auf die Idee kommen und sein Adresslist-Objekt in ein AppAdresslist-Objekt zu casten ... nun ja ... der hat aber spätestens dann ein Problem, wenn ich Methoden in der Klasse, die nicht zum Interface gehören - er aber trotzdem "verbotener Weise" benutzt - umbenenne oder ganz entferne. Wenn es um sensible Daten geht, darf man das natürlich nicht einsetzen ... aber für die "Normalapplikation" reicht das völlig aus.

ich hoffe ich hab dich nicht all zu sehr gequält ...
ich hab mir aber gedacht ... wenn dann richtig ... da das ein grundlegendes Thema in Java ist (haben andere Programmiersprachen auch sowas wie Interfaces ??). Um "richtig" zu code bzw. vorhandene Frameworks benutzen zu können muss man das Prinzip begriffen haben !!!

Viel Spaß beim Ausprobieren ...
Michael

[Ben]

ich finde beide beispiele sehr gelungen. *applaus*
das zweite wird für einen anfänger eventuell noch etwas zu hart sein, da du ja auch das fassaden-pattern verwendest, aber ich finde das hast du ganz gut beschrieben.

btw:
dann war ich aber mit meiner möchtegern-schnittstellen-beschreibung auch gar nicht sooooo weit von deiner erklärung weg

also nochmals: *ThumbsUp*

was vielleicht in Bezug auf "Vererbung" noch ganz interessant ist:

Normalerweise ist Vererbung dann sinnvoll wenn eine sog. "Ist ein" Beziehung besteht.

Um auf Bens Beispiel zu verweisen:

- Ein Auto ist ein Fahrzeug

Oder:

- Ein Kreis ist eine Figur

Etc. pp.[/b]


Bei Interfaces gilt außerdem:
- alle deklarierten Methoden im Interface sind implizit "abstract public"
- alle Attribute sind "final public static"

Das beste Beispiel für die Verwendung von Interfaces ist für mich das Event-Handling unter Java..
Diverse Beispiele hier:
http://www.google.ch/search?hl=de&am...uche&meta=