Klassenerstellung verweigern

[Liberty]

Moin,

ich hab' aus Jux und Dollerei (und weil ich's in nicht allzu ferner Zukunft evtl. auch selbst ausbilden soll) mal wieder ein wenig mit Java angefangen und habe mich an ein altes - rein akademisches, ich geb's ja zu - Problem erinnert, dass mir bisher niemand wirklich beantworten konnte:

Gibt es die Möglichkeit, in einem Constructor einer Klasse die grundsätzliche Erstellung dieser Klasse zu unterbinden.

Ich dachte da zum Beispiel an Situationen, in denen die einem Constructor uebergebenen Parameter keinen Sinn machen, so dass man das neue Objekt gar nicht erst weiter zu bearbeiten braucht, sondern es ohne Umschweife sofort dem GC ueberlässt.

Dann könnte man als Entwickler z.B. ueber folgendes Konstrukt Fehler abfangen:



Objekt Variabe;
if ((Variable = new Objekt(param1, param2, ...)) == null)
{ Fehler }
else
{ weiterarbeiten }


Man könnte das dann noch ueber eine Callback-Methode zur Uebergabe eines Fehlercodes oder so etwas verfeinern.

Hat jemand eine Idee, wie man so etwas umsetzen könnte?

So long,

Liberty

P.S.:
Ich bin rein stilistisch kein Freund von Exceptions, daher kam mir dieser Ansatz in den Sinn...

[nul]

http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
Wirft zwar auch Exceptions, aber das koennte dir evtl. weiterhelfen.

[suso]

:D klar geht das .. und zwar ganz einfach ;)
- mach halt nen private constructor :D *giggle*
- sochle klassen werden oft über statische factory methods erzeugt - aber wenn es keine solche methode gibt - haddu auch keine chance ne klasse mit nem privaten constructor zu instanzieren ;) - -- schau dich mal nach dem buch "SCJP" um - das würd warscheinlich zum unterrichten hilfreich sein ;)

[Fabeltier]

Ich habe momentan genau das gleiche Problem, einige Klassen sollten nur erzeugt werden wenn sie sinnvoll sind, bzw eig. will ich deren Erzeugung schon abfangen, aber dennoch ein Sicherheitsnetz in deren Ctoren einbauen - sind Assertions fuer so etwas geeignet oder sollte man i.allg. in Java lieber ueber Exceptions gehen?

[mwanaheri]

Ich würde in so einem Fall mit Exceptions arbeiten, und zwar mit so was wie einer "InvalidParameterException". Der Vorteil vom Werfen mit Exceptions ist, dass der Programmlauf in der erzeugenden Klasse sauber getrennt werden kann zwischen "alles klar" und "was mach ich, wenn's schief läuft?".

[Fabeltier]

Hm,
Also (ich hoffe es is ok, wenn ich die Frage hier stelle) - Ich habe bspw. eine Gruppe von Klassen, die von einem JPanel abgeleitet sind, auf diesem Panel kann sich eine JCheckBox, ein Textfeld oder auch ein Spinner befinden, der Spinner braucht aber wiederum Optionen in Form eines String[].

Es geht da um Optionen, die den Inhalt von Paremetern von Funktionsaufrufen in einem anderen Programm regeln und von einem Anwender ausgewaehlt und somit dynamisch erzeugt werden.

Es kann sein, dass bspw ein Spinner ausgewaehlt wurde, aber nichts ins Array reingelegt wurde (was unsinnig ist und ich eig. unterbinden will). Aber als Absicherung sollte eben das Panel Objekt "mit_spinner" auch gar nicht erst erzeugt werden koennen - ich denke da an eine weitere Absicherung im Ctor.

Ginge das zB auch mit Assertions, bzw ist das sinnvoll?

Sind assertions genauso "aufwendig" wie Exceptions, ich habe Exceptions immer auch etwas als Performance Killer in Erinnerung oder taeusche ich mich da?

[suso]

hey !
1) mit assertions würd ich eher vorichtig sein ;)
2) müssen bei'm start über die console erst mit -ae od. -enableassertions aktiviert werden !
3) hab ich leider noch immer net genau gecheckt was du willst .. hilft dir der tip mit den private constructoren und den statischen factory-methods nicht ?

[Liberty]

Moin,

bin ich jetzt irgendwie schief gewickelt oder seid ihr mir einfach nur über ;-) : Ich war bis jetzt immer der Meinung, Assertions wären ein reines Debug- und Testkonzept...

Außerdem ist mir aufgefallen, dass hinter meiner Ursprungsfrage eigentlich eine ganz andere Frage steckt, ich denke, dass ich im Grunde auf der Suche nach einem Mechanismus bin, mit dem man einer Klasse Selbstmord befehlen kann, so in der Art "Beim Verlassen dieser Methode (und ein Constructor ist ja am Ende auch nur eine Klassenmethode) werden alle Referenzen auf diese Klasse auf null gesetzt."
Allerdings würde ein solches Verhalten nur in einem Constructor Sinn machen, da dort ja noch sichergestellt ist, dass die Klasse noch nicht im übrigen Programm eingebunden ist und gefahrlos wieder gekillt werden könnte.

Ist auch weiterhin bei mir nur eine rein akademische Frage, im Alltag sind statische Factory-Methoden eigentlich die beste Möglichkeit, da habt ihr schon recht.

So long,

Liberty

P.S.:
Will deshalb nicht extra einen neues Thread aufmachen, aber wenn wir schon dabei sind: Wie bekommt man eigentlich raus, wieviel Speicher eine bestimmte Instanz einer Klasse belegt?
P.P.S.:
Ja, ich weiß, dass man bei Java die Speicherverwaltung der VM überlassen soll, aber irgendwie müsste ich's halt trotzdem wissen ;) und ich bin zu faul, selbst zu suchen :p

[suso]

Hey !
- Ja - mit den Assertions hast du recht - sind eh nur debug und testing - deswegen sagte ich ja auch dass man sie erst extra über console aktvieren muss (*kuz**kuz*) - mit der speicherverwaltung hab ich leider k.a.

[mwanaheri]

Eine Klasse kann keinen Selbstmord begehen. Auch die Methode finalize() zerstört nicht das Objekt, sondern wird beim Zerstören aufgerufen (vom Garbage-Collector). Daher ist das Werfen von Exceptions hier so sinnvoll.
try{
obj = new Object(parameters)
}catch(InvalidParameterException e){
obj = null;
}

Sache erledigt.

[falke2203]

Da es ja eh eine rein akademische Fragestellung ist - grundsätzlich gibt es in Java keine Destruktoren, einzige Möglichkeit für das Entfernen einer Instanz einer Klasse ist das aufsammeln lassen vom GC. Wie bereits erwähnt, funktioniert das aber auch nur, wenn nirgends mehr eine Referenz auf diese (zu löschende) Instanz gehalten wird.
Soll das Erzeugen neuer Instanzen tatsächlich verhindert werden, funktioniert auch die Variante mit dem Auslösen einer Exception im Konstruktor nicht, da zu dem Zeitpunkt, an dem die Anweisungen im Konstruktor abgearbeitet werden, längst eine Instanz dieser Klasse erzeugt wurde (weshalb auch die Verwendung von this-Konstrukten bereits im Konstruktor funktioniert). Die einzige (mir bekannte) Möglichkeit, das Erzeugen von Instanzen bei nicht der gewünschten Semantik entsprechenden Parametern zu unterbinden, ist tatsächlich die Verwendung einer Factory-Methode, in der vor Aufruf des Konstruktors die relevanten Parameter geprüft werden, und ggf. eine Exception ausgelöst wird...

[Liberty]

Moin,

also manchmal vermisse ich bei Java echt die Kontrolle, die einem andere Sprachen ermöglichen, aber egal, denn in diesem Fall war ich auch ein *wenig* blind, denn mit Factory-Methoden lässt sich das Konstrukt, dass ich ganz zu Anfang im Sinn hatte, ja sogar auch realisieren, wenn die Methode als Rückgabewert den Instanzzeiger der neuen Instanz liefert oder eben "null".

So long,
Liberty

[Fabeltier]

hey !
1) mit assertions würd ich eher vorichtig sein ;)
2) müssen bei'm start über die console erst mit -ae od. -enableassertions aktiviert werden !
3) hab ich leider noch immer net genau gecheckt was du willst .. hilft dir der tip mit den private constructoren und den statischen factory-methods nicht ?

Hallo,
Mich interessierte eigentlich nur, ob man diese Dinger als zusaetzliches Mittel in Java zur Verfuegung hat - eben als spezieller Blocker fuer unsinnige Konstruktoren. Da sie bei Java nur zum Debugkonzept gehoeren, beantwortet somit meine Frage voellig.

Ansonsten, danke, ich arbeite bereits mit Factory Methoden, kenne nur eben den Umgang mit Assert nicht.

@Liberty
Ich hatte Deinen Thread in eigenem Interesse missbraucht, meine Frage hatte mit Deinem urspruenglichen Problem nicht mehr viel zu tun, da ich angenommen hatte sie waere schon beantwortet worden. Sry, :D

[Liberty]

Moin!

@Fabeltier:
Kein Thema, irgendwie gehören unsere beiden Fragen eh' im Großen und Ganzen in den gleichen Themenbereich.
Wenn Dich Assertions interessieren, würde ich mich an Deiner Stelle als erstes mit dem JUnit-Framework (http://www.junit.org) auseinandersetzen, da dürfte das Konzept ziemlich klar werden.

So long,
Liberty

[Fabeltier]

Vielen Dank fuer die Antwort, an so Dinge wie JUnit (mit denen ich auch noch nicht wirklich vertraut bin) dachte ich dabei noch gar nicht, super! :)