Einzelnen Beitrag anzeigen

alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#25

Re: Objekterstellung im Konstruktor abbrechen

  Alt 3. Okt 2005, 11:06
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.
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat