Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:design

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

se:design [2010-07-26 17:37]
stefan
se:design [2014-04-05 11:42]
Zeile 1: Zeile 1:
-====== Software-Design ====== 
-**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) 
-  * 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 \cite{Miller2007a} 
se/design.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)