Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:design

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
Nächste Überarbeitung Beide Seiten der Revision
se:design [2009-01-30 15:31]
stefan
se:design [2010-07-26 17:37]
stefan
Zeile 1: Zeile 1:
 ====== Software-Design ====== ====== Software-Design ======
-**nach ​{[quellen:​Goodliffe2008|S. 242ff.]}**+**nach ​\cite[S. 242ff.]{Goodliffe2006}**
   * "There are two ways of constructing a software design: One way is to make it so simple that there are oviously no deficiencies,​ and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."​ (C.A.R. Hoare)   * "There are two ways of constructing a software design: One way is to make it so simple that there are oviously no deficiencies,​ and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."​ (C.A.R. Hoare)
   * Programmierung selbst ist eine Form von Design, da sie artisitisch und kreativ ist   * Programmierung selbst ist eine Form von Design, da sie artisitisch und kreativ ist
Zeile 13: Zeile 13:
   * Triff alle Designentscheidungen im Hinblick auf die Architektur der Software!   * Triff alle Designentscheidungen im Hinblick auf die Architektur der Software!
   * Eine gute Architektur ist einfach: sie kann in einem Satz oder einem simplen Diagramm beschrieben werden!   * Eine gute Architektur ist einfach: sie kann in einem Satz oder einem simplen Diagramm beschrieben werden!
 +
 +===== Designprinzipien =====
 +  * **Encapsulation** \cite{Miller2007a}
 +  * **Loose Coupling** and **High Cohesion** \cite{Larbi2009},​ \cite{Miller2007a}
 +  * **Don'​t Repeat Yourself (DRY)**: Funktionen werden nur einmal implementiert und nicht mehrmals (womöglich gar durch Copy-and-Paste) -> Modularisierung,​ bessere Wartbarkeit \cite[S. 87]{Bleek2008}
 +  * **Speaking Code Principle (SCP)**: der Code muss auch ohne Kommentare verständlich sein -> bessere Wartbarkeit,​ einfachere Einarbeitung anderer Entwickler \cite[S. 87]{Bleek2008}
 +  * **Separation of Concerns (SoC)**: jedes Modul hat genau eine Aufgabe -> Modularisierung,​ bessere Wartbarkeit,​ DRY \cite[S. 87]{Bleek2008}
 +  * ** Tell, don't ask (TDA)**: Klassen sollten nicht nach Werten gefragt, sondern aufgefordert werden, eine Funktion zu liefern (z.B. nicht MwSt-Satz abfragen, sondern auffordern, Mehrwertsteuer zu berechnen) -> verhindert ausufernde Abhängigkeiten zu anderen Klassen, evtl. jedoch Konflikt zu SoC \cite[S. 87]{Bleek2008}),​ \cite{Miller2007a}
 +  * **Single Responsibility Principle (SRP)**: A class should have one, and only one, reason to change. \cite{Martin2009}
 +  * **Open Closed Principle (OCP)**: You should be able to extend a classes behavior, without modifying it. \cite{Martin2009}
 +  * **Liskov Substitution Principle (LSP)**: Derived classes must be substitutable for their base classes. \cite{Martin2009}
 +  * **Dependency Inversion Principle (DIP)**: Depend on abstractions,​ not on concretions. \cite{Martin2009}
 +  * **Interface Segregation Principle (ISP)**: Make fine grained interfaces that are client specific. \cite{Martin2009}
 +  * **Law of Demeter (LoD)**: Avoid long messaging chains like ''​TopClass.Child.Helper.Connection.Close()''​. ​ Instead, open up a new ''​Close()''​ method on the ''​TopClass''​ and hide the entire chain of calls through its children. ​ It's nothing but making sure that ''​TopClass''​ is wearing its underwear (''​Child.Helper.etc''​) under its clothes where it belongs. \cite{Miller2007a}
 +  * **Orthogonal Code**: fasst mehrere Prinzipien zusammen \cite{Miller2007a}
se/design.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)