Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
se:programmierung [2010-08-27 10:43] stefan |
se:programmierung [2014-04-05 11:42] (aktuell) |
||
---|---|---|---|
Zeile 7: | Zeile 7: | ||
* Konstruktoren sollten keine "echte" Arbeit verrichten. \cite{Hevery2008} | * Konstruktoren sollten keine "echte" Arbeit verrichten. \cite{Hevery2008} | ||
* "The most reliable way to minimize the creation of regression bugs is to avoid modifying the existing code." \cite{Miller2007a} | * "The most reliable way to minimize the creation of regression bugs is to avoid modifying the existing code." \cite{Miller2007a} | ||
+ | |||
+ | ===== Single Responsibility Principle ===== | ||
+ | * Validierung sollte auf Ebene des Domänendatenmodells durchgeführt werden und nicht als Teil des Domänenmodells. Beispiel: Prüfung einer gültigen PLZ nicht in Klasse ''Adresse'', sondern in eigener Klasse ''PLZ''. \cite[S.107]{Westphal2012} | ||
+ | * Wenn man richtig konsequent nach SRP arbeiten will, benutzt man semantisch genaue Datentypen für Eigenschaften, z.B. ''Fullname'' oder ''PhoneNumber'' bei ''Person''en. Dadurch baut man sich eine Hierarchie von Datentypen auf: große Datentypen setzen sich aus kleineren Datentypen zusammen. \cite[S.108]{Westphal2012} | ||
+ | * Bei 1:n- oder m:n-Beziehungen liegt häufig auch eine komplexere Semantik vor. Diese sollte in spezielle Datentypen ausgelagert werden. \cite[S.109]{Westphal2012} | ||
===== Werkzeuge ===== | ===== Werkzeuge ===== | ||
Zeile 32: | Zeile 37: | ||
* ''default''-Zweig von ''switch''-Anweisungen explizit implementieren/dokumentieren | * ''default''-Zweig von ''switch''-Anweisungen explizit implementieren/dokumentieren | ||
* Wertebereiche von Variablen im Hinterkopf behalten bei der Wahl eines Datentyps | * Wertebereiche von Variablen im Hinterkopf behalten bei der Wahl eines Datentyps | ||
+ | |||
+ | In \cite[45:00]{RubyRogues47} sprechen sich die Teilnehmer dafür aus, nicht in allen internen Komponenten erneut Datengültigkeitsprüfungen durchzuführen (also auf defensive Programmierung zu verzichten), sondern lediglich in einer "Guard"-Klasse, deren einzige Aufgabe (-> Single Responsibility Principle) es ist, Eingaben zu validieren. Alles, was in das System reinkommt, muss diese zentrale Prüfung bestehen, sodass im Inneren des Systems von gültigen Daten ausgegangen werden kann. | ||
===== Codeoptimierungen ===== | ===== Codeoptimierungen ===== |