Abstrakte Klassen

[.maik.]

Abend.
Ich wollte gerade bei der Insel mit der Oberflächenprogrammierung anfangen. Nun wird da von abstrakten klassen gesprochen . muss ich mich erst in das thema der abstrakten klassen einarbeiten oder werde ich das auch so verstehen ? wenn nicht, koenntet ihr mir ein tut geben, wo es gut erklärt wird ?

danke

Maik

 

[Gast2]

Abstrakte Klasse gehören zu den grundlagen von Java, davon sollte man man gehört haben.
Schau dir doch vllt mal
Java ist auch eine Insel – 6 Eigene Klassen schreiben
an, bzw. wenn du nur nachschauen willst was abstrakte klassen sind:
Java ist auch eine Insel – 6.10 Abstrakte Klassen und abstrakte Methoden

 

[.maik.]

Ich weiß, dass diese Frage jetzt nicht ganz hier rein passt, aber ich mache es mal trotzdem. Wieso ist das folgende nicht zulässig : subklasseReferenz = superklasseReferenz


danke

 

[ARadauer]

weil eine instanz der super klasse nicht unbedingt eine instanz dieser sub klasse sein muss...

 

[.maik.]

mh. bestimmt habe ich gerade einen denkfehler. eig ist es doch genau umgekehrt. die subklasse ist spezialisiert und deshlab muss eine instanz von einer subklasse nicht gleich der instanz der superklasse sein .

 

[Eldorado]

Ein Opel ist ein Auto, ein Auto aber nicht unbedingt ein Opel (bitte jetzt keine Kommentare wegen der Automarke...^^).

 

[redbulls]

Eine abstrakte Klasse ist einfache eine Klasse mit ausschließlich abstrakten Methoden. Eine abstrakte Methoden ist eine Methode, die nicht ausprogrammiert wurde(Es fehlt der Methodenrumpf). Man kann auch keine Instanz einer abstrakten Klasse erzeugen. Man muss erst die Methoden nach seinen Anforderungen vervollständigen

 

[tfa]

Eine abstrakte Klasse ist einfache eine Klasse mit ausschließlich abstrakten Methoden.

Falsch. In abstrakten Klassen können auch Methoden implementiert sein. Theoretisch ist es möglich, dass eine abstrakte Klasse keine einzige abstrakte Methode besitzt.

 

[redbulls]

Sorry eine abstrakte Klasse mit ausschließlich abstrakten Methoden ist ein Interface, aber sobald eine Klasse eine abstrakte Methode hat, muss sie abstrakt sein. Meiner Meinung nach gibt es keine abstrakte Klasse ohne mindestens eine abstrakte Methode.

 

[frapo]

Meiner Meinung nach gibt es keine abstrakte Klasse ohne mindestens eine abstrakte Methode.

Doch, gibt es:

public abstract class AbstractTestClass {
	void testMeth1() {
		System.out.println("TestMeth 1");
	}
	
	void testNeth2() {
		System.out.println("TestMeth 2");
	}
}

 

[nrg]

Sorry eine abstrakte Klasse mit ausschließlich abstrakten Methoden ist ein Interface

wieder falsch. eine Klasse, die ein Interface implementiert, muss automatisch alle Methoden vom Interface implementieren. egal ob diese abstract sind oder nicht.

 

[Landei]

tfa hat recht, und nicht nur "theoretisch". Von manchen Klassen ist es einfach nicht sinnvoll, Instanzen zu bilden, selbst wenn man alle Methoden implementieren kann. Wenn ich z.B. Kunde und Lieferant in meinem System habe, und deren gemeinsame Eigenschaften in einer Klasse Person bündele, dann will ich trotzdem sicherstellen, dass niemand [c]new Person()[/c] schreiben kann, auch wenn keine Methode in Person abstrakt ist.

 

[tfa]

tfa hat recht, und nicht nur "theoretisch". Von manchen Klassen ist es einfach nicht sinnvoll, Instanzen zu bilden, selbst wenn man alle Methoden implementieren kann. Wenn ich z.B. Kunde und Lieferant in meinem System habe, und deren gemeinsame Eigenschaften in einer Klasse Person bündele, dann will ich trotzdem sicherstellen, dass niemand [c]new Person()[/c] schreiben kann, auch wenn keine Methode in Person abstrakt ist.

Da kann man sich auch anders behelfen. Zum Beispiel durch nicht-öffentliche Konstruktoren und Fabrik-Methoden oder eine Factory. An eine Klasse abstract zu schreiben, ohne dass es eine abstrakte Methode gibt, halte ich für verwirrend.

 

[Landei]

Wieso? Abstrakt heißt, dass diese Klasse ausschließlich dazu da ist, von anderen erweitert zu werden - das hat mit den Methoden gar nicht unmittelbar zu tun. Offensichtlich hielten es die Java-Gurus für wichtig, dass man auch ohne abstrakte Methoden eine abstrakte Klasse haben kann - ansonsten hätte man einfach die Konvention einführen können, dass eine Klasse "automatisch" mit der ersten abstrakten Methode auch abstrakt wird, und kein [c]abstract[/c] auf Klassenebene zuzulassen.

Und es gibt auch Klassen in der Java-API, die abstrakt sind, obwohl alle Methoden implementiert sind, z.B. die ganzen Adapter-Klassen wie [c]MouseAdapter[/c], [c]WindowAdapter[/c]...

 

[tfa]

ansonsten hätte man einfach die Konvention einführen können, dass eine Klasse "automatisch" mit der ersten abstrakten Methode auch abstrakt wird, und kein abstract auf Klassenebene zuzulassen

Das wär ja wirklich furchtbar. Dann steigt man ja gar nicht mehr durch.

Trotzdem finde ich diese Praktik unschön. Auch die Tatsache, dass das in der Java-API so gemacht wird, ändert daran nichts. Da stecken aber noch viel schlimmere Unschönheiten drin.

 

[bygones]

Wieso? Abstrakt heißt, dass diese Klasse ausschließlich dazu da ist, von anderen erweitert zu werden

du hast aber anfangs davon gesprochen abstract zu verwenden, wenn du nicht willst dass sie instanziiert wird. Das sind 2 versch. Sachen.

Bei der ersten stimme ich tfa zu - um eine Instanziierung zu verhindern soll man nicht abstract nehmen, weil es eben, wie du wiederum richtig sagst vor allem Vererbung signalisiert.

 

[Landei]

Na ja, eine Klasse, die weder instantiiert wird, noch als Basisklasse dient, ist relativ sinnfrei (*), oder? Insofern hängen die beiden Punkte schon sehr eng zusammen.

(*) Sieht man einmal von rein statischen "Utility-Klassen" ab.

 

[nrg]

also ich habe öfters config-Klassen verwendet, die demnach nur einmal exisiteren. Config wird geladen und ist danach aus jeder anderen Klasse durch die statischen Methoden abrufbar. Diese Klassen habe ich dann auch abstract deklariert, weil eine Instanziierung da für mich keinen Sinn macht. Ist das falsch und sollte besser durch einen private-Konstruktor gelöst werden?

 

[bygones]

Ist das falsch und sollte besser durch einen private-Konstruktor gelöst werden?

macht sowas für dich Sinn ?

public class DummyTest {
    public static void main(String[] args) {
        Foo foo = new Bar();
        Bar.foo();
    }
}

abstract class Foo {
    public static String foo() {
        return "foo";
    }
}

class Bar extends Foo {

}

 

[nrg]

nicht so. daraus schließe ich, dass man sowas lieber mit Konstruktorsichtbarkeit löst?

 

[bygones]

nicht so. daraus schließe ich, dass man sowas lieber mit Konstruktorsichtbarkeit löst?

richtig, somit wird gleich signalisiert was die Intension ist. Wenn du ganz formell sein willst machst du dann deine Klasse auch noch final

 

[Landei]

In dem Fall sollte man lieber den Konstruktor private machen, das drückt besser aus, was man will (keine Instanzen, keine Vererbung). Am besten finde ich den Stil mit einer "selbstdokumentierenden" Fehlermeldung, damit es wirklich ganz klar ist, und nicht jemand versehentlich den "leeren" Konstruktor rauslöscht oder über eine statische Methode aufruft:

public class Foo {
    private Foo() {
        throw new UnsupportedOperationException("Utility class");
    }

    public static String foo() {
        return "foo";
    }
}