hi,
ich wollte mal wissen was genau abstrakte Methoden sind; soviel ich weiß sind das doch Methoden, die keinerlei Programmcode enthalten sondern einfach nur deffiniert wurden und die man erst durch eine Vererbung erweitern kann (z.B. interfaces). Das macht aber in meinen Augen keinen Sinn. Warum sollte ich eine Methode als abstract deklarieren, da kann ich sie doch genauso gut gleich komplett deffinieren ...

[Ben]

Hi ,

Zitat von WurstBrot

ich wollte mal wissen was genau abstrakte Methoden sind; soviel ich weiß sind das doch Methoden, die keinerlei Programmcode enthalten sondern einfach nur deffiniert wurden

das stimmt.

Also eine abstrakte Methode ist z.B. das hier

PHP-Code:

public abstract void machWas(); 


Wenn wir nun diese Methode in einer Klasse A definieren und dann von dieser Klasse A eine Klasse B ableiten, dann ist Klasse B dazu gezwungen die Methode machWas() zu implementieren.

Das ist das gleiche Prinzip wie bei Interfaces. In Interfaces werden auch nur die Methoden definiert, welche dann in den implementierenden Klassen ausformuliert werden müssen.

Der Sinn ist der, dass man eine Schnittstelle anbieten kann, welche Grundfunktionalitäten enthält, aber weiterhin Methoden zur Verfügung stellt, welche je nach erbender Klasse unterschiedlich implementiert sind.

Beispiel:

PHP-Code:

class A {

    public abstract void machWas();
    public void print() {
        System.out.println("Eine kleine Ausgabe in der Klasse A festgelegt.");
    }

} 


PHP-Code:

class B extends A {
    
    public void machWas() {
        System.out.println("Hier in der Methode machWas() der Klasse B");
    }
} 


PHP-Code:

class C extends A {
    
    public void machWas() {
        System.out.println("Hier in der Methode machWas() der Klasse C");
    }
} 


PHP-Code:

class Demo {

    public static void main(String[] args) {
        A class1 = new B();
        A class2 = new C();

        class1.machWas();
        class2.machWas();
    }

} 


Spiel einfach mal etwas damit herum.

Grüße Ben.

[Sym]

Nehmen wir an, Du baust eine Klasse Auto. Das eine ist ein Einspritzer und das andere nicht. Dann hast Du verschiedene Arten, wie die Zündung funktioniert - ein großer Teil bleibt aber gleich.

Also implementierst Du alles aus, bis auf z.B. die Zündung. Diese Methode braucht aber jedes Auto. Also sagst Du nur, dass wenn jemand ein Auto bauen möchte (und entsprechend von Deiner Klasse erbt), die Leute sich selbst um die Zündung kümmern müssen - weil es halt verschiedene Arten gibt.

Ich hoffe, das ist einigermaßen erklärend. Hatte gerade kein besserer Beispiel zur Hand.

[ehli75]

Dann will ich hier auch noch gleich 'n Beispiel in die Rund werfen:

Stellen wir uns vor, du hast (um zum klassischen Beispiel zu kommen) eine Klasse Person, und von der abgeleitet gibt es dann die Klassen Student und Professor. Das funktioniert auch ganz toll. Nun soll ein Student und ein Professor auch in der Datenbank gespeichert werden. ist ja kein Problem, da bekommt jede Klasse eine Methode save(), die das erledigt. Nach Jahren kommt dann noch eine Klasse Putzfrau dazu ... und dort wird vergessen, diese Methode reinzuschreiben. Schon gibt es zur Laufzeit Fehler, da ja die Klassen mittels Refelxion instanziiert werden (deshalb wird der Kompiler auch nicht meckern!). ... ich weiß was du jetzt denkst ... "Dafür gibt es doch Interfaces ..." ... eigentlich hast du Recht ... aber deine abstracte Klasse hat ja noch mehr Vorteile:
Nun haben wir noch das Problem, dass JEDE Unterklasse von Person in der Methode save() fast das gleiche macht: Connection holen, das Insert machen, wenn alle OK dann commiten und im Fehlerfall ein Rollback. Wäre doch schön, wenn wir das an EINER Stelle machen könnten ...
und an da kommt unsere abstracte Klasse Person ins Spiel !

PHP-Code:

public abstract class Person {
    protected abstract void save( Connection con ) throws Exception;

    public final void save() {
        Connection con = null;
        try{
            con =  .... //Connection irgendwie organisieren
            con.setAutocommit( false );
            save( con );
            com.commit();
        }
        catch( Exception e ){
            con.rollback();
            // weitere Fehlerbehandlung
        }
        finally{
            if( con != null )
                 con.close();
        }
    } 


Was haben wir nun davon? ... ganz einfach ... die Unterklassen von Person müssen sich in keinster Weise darum kümmern, wie man sich eine Connection besorgt ... oder bei einem eventuellen Fehler die Transaktion zurückzurollen. Und da die Methode save(Connection) abstract ist, "weiß" die Klasse Person, dass JEDE Unterklasse auf jeden Fall eine solche Methode implementiert hat. Von außen kann nur die Methoden save() von Person aufgerufen werden, da save(Connection) protected ist. Und da es ja gemeine Leute gibt, die immer aus der Reihe tanzen müssen und dann einfach save() überschreiben und Schwachsinn machen wollen, machen wir noch fix die Methode save() final ... dann hat sich das auch erledigt !
Einen weiteren Vorteil bringen abstracte methoden hintenrum noch mit. Da ja, sobald eine Methode abstract ist, die ganze Klasse abstract sein muss, kann man von dieser Klasse keine Instanz erzeugen. Klingt vielleicht doof, aber ist (meistens) genau das, was man haben will. Was würde dir ein Objekt der Klasse Person nützen ... NIX ... gar NIX ... entweder ist's ein Student, ein Prof oder 'ne Putzfrau. So stellst du sicher, dass jemand, der deine Klassen benutzt, auch keinen Sch... damit macht.

Wenn du noch mehr Erklärungen brauchst, dann meld dich einfach !!
Michael

thx für die ausführlichen Erklärungen! Ich glaub jetzt hab ichs verstanden; nur der letzte Beitrag hat mich etwas verwirrt, weil ich erst mit dem Java angefangen hab