Verhinderung der Instanziierung

Hallo

Ist es sinnvoll Instanziierung von Objekten durch den Einsatz von abstract in der Klasse zu verhindern?

class abstract Foo {
    // keine abstrakten Methoden
}

void test() {
    new Foo(); // geht nicht
    new Foo(){}; // geht
}

Ich denke, daß ist nicht gerade das, was man sich von einer abstrakten Klasse erahnt… Was haltet Ihr davon?

Danke für Eure Meinungen

Abstrakte Klassen machen eigentlich nur als Basisklassen für nicht-abstrakte Klassen Sinn.

Haengt vom Einsatz ab.

Abstrakte Klassen koennen vererbt werden und deren Kinder (wenn konkret) instanziert werden, somit auch die abstrakte Klasse (bzw ueber anonyme Klassen).

Wenns nur darum geht nur die Instanzierung zu verbieten, bietet sich ein private Konstruktor an

Ich denke, daß ist nicht gerade das, was man sich von einer abstrakten Klasse erahnt…

die Nicht-Instanziierung ist nahezu die genaue Definition von abstrakten Klassen, in Perfektion getrieben kommt dann Interface heraus
wenn du das nicht willst, dann schreibe schlicht keine abstrakten Klassen, dazu wird man ja nicht gezwungen,

wenn man aber das Konzept ‚Methoden fehlen‘ hat, wie soll sich dann ein Objekt dieser unbestimmten Klasse verhalten?

edit: hmm, ok, so war die Frage also gemeint, ich versteh ganz schön viel falsch die letzte Zeit…

Öh, was genau willst du haben?

Das erste ist ein Konstruktoraufruf von Foo (geht logischerweise nicht), das zweite von einer Anonymen Subklasse von Foo.

Willst du verhindern, dass man Instanzen von der Klasse erzeugt: Privaten Konstruktor erstellen, ggf. noch eine Exception in den Konstruktor.
Willst du verhindern, dass man Subklassen erzeugen kann: Mach die Klasse final.

Gruß

Vielen Dank @all, daß denke ich nämlich auch.

Konkret habe ich das bei Entity-Klassen gesehen, wo jemand wollte, daß nicht die Basisklassen, sondern nur deren Erweiterungen instanziiert werden sollen können. Diese Erweiterungen benötigen aber einen public Defaultkonstrukter, da sie z.B. von Hibernate instanziiert werden.

Das ist für mich ein Paradebeispiel für eine abstrakte Klasse.
Ich mache Klassen abstrakt, wenn sie
[ol]
[li]nicht instanziiert werden dürfen und[/li][li]sie erweitert werden müssen, um verwendet zu werden.[/li][/ol]
Wenn in der Basisklasse keine abstrakten Methoden sind - ist doch egal!

[QUOTE=cmrudolph]Das ist für mich ein Paradebeispiel für eine abstrakte Klasse.
Ich mache Klassen abstrakt, wenn sie
[ol]
[li]nicht instanziiert werden dürfen und[/li][li]sie erweitert werden müssen, um verwendet zu werden.[/li][/ol]
Wenn in der Basisklasse keine abstrakten Methoden sind - ist doch egal![/QUOTE]

Eben! Eine abstrakte Klasse hat die Aufgabe eine Instanziierung zu verhindern und KANN abstrakte Methoden enthalten, muss aber nicht. Das ist lediglich andersrum der Fall, eine Klasse, die abstrakte Methoden beinhaltet, MUSS abstrakt sein. An der Tatsache, dass eine Klasse keine abstrakten Methoden hat, würde ich mich daher gar nicht orientieren.

Ich kann mir dafür leider keinen Anwendungsfall vorstellen.

Wenn ich eine Oberklasse habe, die ich in jeder Unterklasse benötige, diese aber nicht spezialisiere, warum dann nicht einfach ein Feld dafür anlegen?

Angenommen alle meine Objekte müssen irgendwie Foo zurückliefern, warum kein gemeinsames Interface, dass die Methode getFoo()anbietet?

Gruß

[quote=Firephoenix]Ich kann mir dafür leider keinen Anwendungsfall vorstellen.[/quote]Zum Beispiel könnte die abstrakte Klasse immer “default-Implementierungen” für alle Mehoden mitbringen. Kann ja sein, dass sich die konkreten Klassen nicht in allen Methoden unterscheiden, und jede Methode der Basisklasse von midestens 2 Spezialisierungen übernommen werden kann…
Als Beispiel fallen mir da Default-Implementierungen für Listener-Interfaces mit mehreren Methoden ein…

bye
TT

Gerade wenn man bei JPA Entities vererbt, hat man leider gewisse Annotations, die in der gemeinsamen Oberklasse vorhanden sein müssen. Angenommen, man hat zum Beispiel die Oberklasse „Lagerplatz“ und die Unterklassen „Regalplatz“ und „Kommissionierplatz“ und man möchte diese Entities Single-Table verwalten, also alle repräsentationen in der selben Tabelle speichern. Dann muss man in der Oberklasse diese Tabelle (und z.B. noch eine Discriminator-Column) spezifizieren, möchte aber unbedingt vermeiden dass irgendjemand die Oberklasse instanziiert und abspeichert.

@Timothy_Truckle & @inv_zim
Beide Fälle hatte ich sogar selbst schon, manchmal hat man echt ein Brett vor dem Kopf :rolleyes:

http://i1.ytimg.com/vi/z-BwGbxcgvw/hqdefault.jpg:smiley:

bye
TT

Danke @all