Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:programmierung

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
se:programmierung [2010-08-27 10:32]
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 =====
Zeile 79: Zeile 86:
  
 ==== Code is considered to be "​done",​ when: ==== ==== Code is considered to be "​done",​ when: ====
-**nach ​[[http://​www.des-eisbaeren-blog.de/​post/​2010/​07/​22/​Wann-ist-Code-e2809cfertige2809d.aspx|Golo Roden, 2010]]**+**nach ​\cite{Roden2010b}**
   - It does satisfy all its functional and non-functional requirements.   - It does satisfy all its functional and non-functional requirements.
   - It does not contain any known errors.   - It does not contain any known errors.
se/programmierung.1282897934.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)