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.