Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:design

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung
Vorhergehende Überarbeitung
se:design [2009-01-30 15:22]
stefan angelegt
se:design [2014-04-05 11:42] (aktuell)
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
 +  * "​There'​s never time to do it right, but there'​s always time to do it twice."​
 +  * Programmierer stehen in der Verantwortung Qualitätscode abzuliefern und für die benötigte Zeit zu kämpfen, während Manager diese Zeit einsparen müssen.
 +    * Nur die Programmierer selbst können rechtfertigen,​ dass und warum mehr Zeit benötigt wird (Vergleich mit einem Arzt, dessen Pflicht es ist, sich vor der Behandlung die Hände zu waschen, egal was der "​Kunde"​ verlangt).
 +  * Module müssen...
 +    * eine hohe Kohäsion aufweisen! Schwache Kohäsion bedeutet fehlerhafte Dekomposition!
 +    * möglichst lose gekoppelt sein!
 +    * eine klare API haben!
 +  * Designe änderbare Programme, aber keine hoffnungslos generalisierten Module.
 +  * 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!
 +
 +===== 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}
se/design.1233325373.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)