Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
se:design [2010-05-03 10:47] 127.0.0.1 Externe Bearbeitung |
se:design [2014-04-05 11:42] (aktuell) |
||
---|---|---|---|
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, "Orthogonality is the ability to change a conceptual part of the software system while minimizing impact to other parts of the software system" \cite{Miller2007a} |