Create abbrechen

[Jelly]

Zitat:

Zitat von Elvis

Assertions sind dafür da deinen Code zu prüfen. Niemals um Dinge zu prüfen, die von außen/ von Benutzern deiner Klasse rein geworfen wurden.
Denn Assertions werden normalerweise im Release ausgeschaltet.

Das ist richtig. Aber ich bin im Beispiel davon ausgegangen, dass im final Release die Fehler erkannt sind. Das ist ne Interpretationssache der Frage.

Wenn ich eine Klasse mit TKlasse.Create (123) instanziere anstatt mit TKlasse.Create(124), so fliegt mir die Assertion um die Ohren, und ich kann den Code bereinigen. Nach Testen tritt der Fehler nicht mehr auf, und im Final Release kann ich beruhigt die Assertion ausschalten.

Aber Du hast Recht. Wenn es wirklich um logische Überprüfungen geht, so ist eine Exception die erste Wahl.

Ich bin von ersterem ausgegangen. Wir haben bei uns einige visuelle Klassen, die im Code instaziert werden und im Form dargestellt werden. Und wenn die 30 Instanzen einmal laufen, so wird sich daran auch nie mehr was ändern. Ich kann also während der Entwicklung ALLE Fälle testen, und bin mir demnach sicher, im Final Release werden auch keine Fehler mehr auftreten.

[Elvis]

Schaue mal hier vorbei: madExcept

[alzaimar]

Zitat:

Zitat von Elvis

Das Zuweisen einzelnener Eigenschaften lässt es aber nicht zu einen konsistenten Zustand zu garantieren.
Änder ich Eigenschaft1 zu "X" wäre meine Instanz vllt ouchy banana und der Setter springt mir ins Gesicht.
Er kann ja nicht wissen, dass ich Eigenschaft2 direkt danach auch "Y" ändern wollte.
Ein Konstruktor, dem beide Werte übergeben werden, und der sie in einer "Transaktion" ändern kann ist hier natürlich vorteilhaft.
Genau wie es oben genannte Factory wäre.

Wenn mein Konstruktor knallen könnte, überlege ich mir sehr genau, ob ich eine Konsistenzprüfung dort einbaue. Ich bevorzuge liebe eine 'Prepare'-Methode, die die Eigenschaften prüft, oder lass das von der Methode ausführen, die konsistente Eigenschaften voraussetzt. Um Eigenschaften konsistent zu setzen, würde ich sie logisch zusammenfassen: Entweder als Klasse oder Record. Wenn das noch Overkill ist, dann schreibe ich mir eine 'Set'-Methode à la 'SetBounds'.

Ein TFileStream z.B. hätte man auch analog zur 'AssignFile/ReSet'-Metapher implementieren können: Der Konstruktor entspräche dann dem 'AssignFile': Nur müsste man dann eine Zeile mehr schreiben.

[Elvis]

Zitat:

Zitat von alzaimar

Wenn mein Konstruktor knallen könnte, überlege ich mir sehr genau, ob ich eine Konsistenzprüfung dort einbaue. Ich bevorzuge liebe eine 'Prepare'-Methode, die die Eigenschaften prüft, oder lass das von der Methode ausführen, die konsistente Eigenschaften voraussetzt. Um Eigenschaften konsistent zu setzen, würde ich sie logisch zusammenfassen: Entweder als Klasse oder Record. Wenn das noch Overkill ist, dann schreibe ich mir eine 'Set'-Methode à la 'SetBounds'.

Ein TFileStream z.B. hätte man auch analog zur 'AssignFile/ReSet'-Metapher implementieren können: Der Konstruktor entspräche dann dem 'AssignFile': Nur müsste man dann eine Zeile mehr schreiben.

Solange man sich wirklich Gedanken macht über den Zustand eines Objektes, sollte es kein Richtig & Falsch geben.
Dein Weg wäre sicherlich genauso OK, wie ein anderer. Ich selbst mag es auch lieber parameterlose Konstruktoren zu haben und solche Dinge über Instanzmethoden zu lösen. Nur dadurch kann man überhaupt erst Abtraktionen und Interfaces benutzen.