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!

• 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}