Objekterstellung im Konstruktor abbrechen

[mschaefer]

Moin, moon

ja die Exceptions stehen derzeit wohl als geeignet fest. Da hat es von keinem nennenswerte Kritik gegben. Beim Thema Vorabprüfung (durchaus mit Exception) oder Prüfung im Creator zeichnet sich ja ein Muster ab. Einen Aspekt mag ich nochmal einwerfen. Für den Anwender ist es natürlich günstig, wenn er sieht ob eine Funktion verfügbar ist. Also wenn ein Menüpunkt zu einem Formular aktiv ist oder inaktiv. Für diesen wäre es natürlich günstig, wenn bei Aufruf des Menues geprüft wird. Das schließt natürlich eine Überprüfung im Creator für aufwendigere Prüfungen nicht aus.

Grüße // Martin

[Robert_G]

Zitat von Flocke:

Und wenn man dieses Konzept sauber durchzieht, dann braucht man keine Vorab-Checks mehr!

Ganz so extrem würde ich es nicht ausdrücken...
Eine Exception auszulösen kostet schließlich auch etwas crunch time.
Aber generell ist es logisch, dass eine Klasse, die im Konstruktor einen Dateinamen will, diese auch öffnen will.
Weiter ist es logisch, dass es knallt wenn die Klasse mit der Datei nicht das machen kann, was sie will.
Das sollte für die meisten auch nix neues sein... Schließlich dürfte hier jeder schonmal eine Instanz eines FileStream erzeugt haben.
Ich verstehe nur nicht ganz (eigentlich üerhaupt nicht) warum man das in eine Form-Ableitung stopfen will.
Das ist so flexibel wie ein Hummer auf der Go Cart-Bahn oder ein Navi, dass fest mit dem Rahmen verschweißt ist, so dass man sich ein neues Auto bauen muss um die jährliche Update DVD verwenden zu können...

[Flocke]

Zitat von Robert_G:

Zitat von Flocke:

Und wenn man dieses Konzept sauber durchzieht, dann braucht man keine Vorab-Checks mehr!

Ganz so extrem würde ich es nicht ausdrücken...

Die überzogene Ausdrucksweise war durchaus Absicht!

Zitat von Robert_G:

Eine Exception auszulösen kostet schließlich auch etwas crunch time.

In dem Fall kann man das wohl vernachlässigen, weil das langsamste der User bei Drücken auf den OK-Knopf im Fehlerdialog sein wird...

[mschaefer]

Moin,

Vom Prinzip her wäre es natürlich schon richtiger die Funktionalität von der Anzeige zu trennen und da sehe ich Roberts Kritik das in den Formularcreator zu legen. Das Problem ist aber durch die VCL eigentlich nicht wirklich lösbar.

Grüße // Martin

[alzaimar]

Zitat von Robert_G:

Aber generell ist es logisch, dass eine Klasse, die im Konstruktor einen Dateinamen will, diese auch öffnen will.

Nö, ist gar nicht logisch. Beispiel:

Delphi-Quellcode:

Type
  TFileTool = Class (TSomething)
  ...
  Public
    Constructor Create (aFileName : String);
    Procedure OpenForRead;
    Procedure OpenForWrite;
    Procedure CreateFile;
    Function FileSize : Integer;
    ....
  End;

Der Konstruktor macht noch gar nichts. Er weiss doch nicht, was ich mit dem Parameter anstellen will.

Ich würde hier überhaupt keine Regeln festsetzen, ob man im Konstruktor alles abchecken soll, oder nicht. Es ist eine Frage der Herangehensweise. Was IST das Objekt? Wozu ist es da? Danach richtet sich dann, was der Konstruktor machen sollte. In meinem fiktiven Beispiel instantiiert der bloss das Objekt und schreibt von mir aus den Parameter in ein privates Feld. Das wars dann aber. Man könnte hier z.B. nur prüfen, ob der Name gültig ist, oder nicht. Aber wenn ich den Namen später austauschen kann, dann bringt das auch nicht viel, weil die Gültigkeit des Parameters beim Konstruktor doch noch gar keine Rolle spielt.

Beim Konstruktor eines Formulars wird ja ne ganze Menge angestellt (Handles holen etc.). Da würde ich mir schon überlegen, ob da nicht mal eine Überprüfung nach dem Motto "Can I Create it?" nicht doch sinnvoll wäre. Aber, wie Flocke schon erwähnte, und was durch die Murphyschen Grundregeln ('If it can go wrong, it WILL go wrong') manifestiert ist, Exceptions lauern überall.

Ich kann natürlich Exceptions auch anders interpretieren, nämlich als 'Ausnahme'. Sind sinnlose Parameter dann Ausnahmen? Oder sind Ausnahmen wirkliche Programm(ier)fehler, die die Kacke zum Dampfen bringen? Das sei doch jedem selbst überlassen. Ich finde, man sollte sich darüber Gedanken machen, und die Linie dann mehr oder weniger durchziehen. Denn ein Programm wird umso übersichtlicher und stabiler, je orthogonaler ich meine (Programmier-) Philosophie und Interpretation dort einfliessen lasse. Dann weiss ich, das eine Exception ein GAU ist, IMMER (oder eben nicht, je nach Philosophie).

Es ist immer eine Frage des Geschmacks, wie ich meine Flusskontrolle realisiere. So hat z.B. die Rückgabe von Statuswerten auch seine Berechtigung, nämlich dann, wenn ich mich nicht immer drum scheren muss, ob es nun geklappt hat, oder nicht. Bei einem Konstruktor ist das natürlich selten sinnvoll, weil ich i.A. noch etwas mit dem Objekt anstellen will.

[Marphy]

Hallo zusammen,
danke für die interessante Diskussion.

Ich würde sagen, es ist abhängig von der Situation, wie man das Ganze nun realisiert. In meinem Falle (den ich in den vorherigen Postings ja wirklich schon zu genüge beschrieben habe ) ist der beste Weg die Exceptions, wie gesagt. Sicher, man könnte (sicherheitshalber) noch triviale Vorprüfungen wie z.B. FileExists() vorneanhängen. Aber wie gesagt, ein solcher Festplattenzugriff ist wahrscheinlich noch langsamer als ein gescheiterter Formularaufbau... Aber wir drehen uns glaube ich im Kreis.

Zitat von alzaimar:

Denn ein Programm wird umso übersichtlicher und stabiler, je orthogonaler ich meine (Programmier-) Philosophie und Interpretation dort einfliessen lasse.

Aha.

Gruß, Marco

[alzaimar]

Zitat von Marphy:

Zitat von alzaimar:

Denn ein Programm wird umso übersichtlicher und stabiler, je orthogonaler ich meine (Programmier-) Philosophie und Interpretation dort einfliessen lasse.

Aha.
Gruß, Marco

Was ich damit sagen will, ist das die inharene Transubtraktionsintoxokarthinartransestenz als Kernstück einer zukunftsweisenden Technologie diktional kontraindiziert.

Oder, anders ausgedrückt: Wenn ich weiss, was und wie ich programmiere (also meinen Stil durchziehe), dann werden Programme automatisch stabil(er) und wartbar(er).

Oder, noch anders ausgedrückt: Erst planen, dann coden.

[Marphy]

Hallo alzaimar,
ok, jetzt hab ich's verstanden...

Gruß, Marco

[tigerman33]

Zitat von alzaimar:

Was ich damit sagen will, ist das die inharene Transubtraktionsintoxokarthinartransestenz als Kernstück einer zukunftsweisenden Technologie diktional kontraindiziert.

Wow! Wo lernt man denn solche Sätze zu bilden?

Ob ich dir in der Sache zustimme, bin ich mir aber nicht ganz sicher. An "erst denken, dann coden" besteht zwar nicht viel Zweifel, aber IMHO nur insofern sich das auf die Sachfragen bezieht. Solange die sauber gelöst werden, ist der Stil, denke ich, mehr oder weniger egal.

[Marphy]

Hallo zusammen,
okay, da wir nun mehr oder weniger vom bereits gelösten Thema abkommen, ist es denke ich nun an der Zeit, diesen Thread offiziell als erledigt zu kennzeichnen.
(Solch einen Button sollte nicht nur bei "offenen Fragen" geben ).

Ich danke euch für die interessante Diskussion!

Bis auf bald,
Marco

P.S.: Ach ja, vielleicht könntet ihr mal schnell im VCl/Controls-Forum vorbeischauen? Da ist leider noch so eine "dumme" Frage von mir offen und wir/ich komme(n) einfach nicht weiter...