Commit ea0e0804 authored by Andreas Zwinkau's avatar Andreas Zwinkau
Browse files

Mehr Tipps zum Entwurf

parent 9e5a2e92
......@@ -196,26 +196,88 @@ Es darf \textbf{keinen Spielraum für Interpretationen} offen lassen.
\section{Entwurf}
\begin{quote}
Design is the art of separation, grouping, abstraction, and hiding. The fulcrum of design decisions is change. Separate those things that change for different reasons. Group together those things that change for the same reason.
---Uncle Bob Martin
\end{quote}
\subsection{Inhalt}
\begin{itemize}
\item Detaillierte Beschreibung \emph{aller} Klassen
\item Beschreibung von charakteristischen Abläufen (Testszenarien?)
anhand von Sequenzdiagrammen
\item Identifikation von Modulen
\item Aufteilung in Klassen/Pakete
die unabhängig voneinander implementiert und getestet werden können.
Vorgriff auf den Implementierungsplan.
\item Identifikation von Entwurfsmustern
Mit Blick auf den Implementierungsplan.
\item Vollständiges großformatiges Klassendiagramm im Anhang
\item (Optional) Identifikation von Entwurfsmustern
um Struktur gröber zu beschreiben.
\item Vermeidung von Abhängigkeitszyklen.
Design Patterns um Abhängigkeiten zu entfernen:
\end{itemize}
\subsection{Bewertung eines Entwurfs}
Hier ein paar Tipps, wie man einen Entwurf einschätzen kann.
Paradoxe Anforderungen zeigen, dass gutes Design ein Kunst ist.
\begin{itemize}
\item Geheimnisprinzip (information hiding) beachtet?
Jede Entwurfsentscheidung sollte in genau einer Klasse gekapselt sein,
so dass eine Änderung dieser Entscheidung
auch nur diese eine Klasse betrifft.
Allgemein sollte ein Klasse/Paket möglichst wenig interne Details
nach außen preisgeben.
\item Lose Koppelung zwischen Klassen/Paketen?
Abhängigkeiten zu fremden Schnittstellen
machen spätere Änderungen aufwendiger.
Im UML Diagramm sollten möglichst wenig Verbindungen
zwischen Klassen zu sehen sein.
Siehe auch Law of Demeter.
\item Starke Kohäsion innerhalb von Klasse/Paket?
Wenn Methoden einer Klasse eigentlich unabhängig voneinander sind,
ist es ein Zeichen,
dass eine Auftrennung in zwei Klassen sinnvoll sein könnte.
Kohäsion führt zu besserer Wiederverwendbarkeit der einzelnen Klassen.
\item Klassen/Pakete sind gleichzeitig erweiterbar und stabil?
Erweiterbarkeit bei stabilem Interface ist der große Vorteil
von objekt-orientertem gegenüber proceduralem Entwurf,
der durch Vererbung und Polymorphie erreicht wird.
Siehe auch Open-Closed Principle.
\item Liskovsches Substitutionsprinzip bei Vererbung erfüllt?
Unterklassen sollte alle Vor- und Nachbedingungen
und alle Invarianten der Oberklasse erfüllen.
Andernfalls kommt es zu Fehlern,
wenn eine Unterklasse als Oberklasse verwendet wird.
\item Verhalten von Implementierung getrennt?
Das Verhalten (Was soll getan werden) ändert sich sehr viel häufiger
als die Implementierung (konkrete Algorithmen).
Beispielsweise sind Sortieralgorithmen recht statisch,
während die Frage wonach sortiert werden soll,
sehr flexibel sein sollte.
\item Keine zyklischen Abhängigkeiten?
Beispielsweise ist eine zyklische Abhängigkeit
von Konstruktoren schlicht nicht möglich.
Eine zyklische Abhängigkeit von größeren Modulen bedeutet,
dass man alles auf einmal implementieren muss,
bevor irgendwas funktioniert.
Entwurfsmuster um Abhängigkeiten zu entfernen:
Observer, Visitor, Strategy
\item Vollständiges großformatiges Klassendiagramm im Anhang
\item Lokalitätsprinzip beachtet?
Eine Klasse/Paket/Methode sollte für sich verständlich sein,
ohne das Kontext notwendig ist.
\end{itemize}
\subsection{Mehr Links}
\begin{itemize}
\item \href{https://github.com/MatzeB/texdoclet}{TeXdoclet}
um mit JavaDoc \LaTeX{} zu erzeugen.
Das ermöglicht den automatischen Flow: ArgoUML $\rightarrow$ JavaDoc+TeXdoclet $\rightarrow$
\LaTeX{} $\rightarrow$ Section \enquote{Klassenbeschreibung} im Entwurf.
um mit JavaDoc \LaTeX{} zu erzeugen.
Das ermöglicht den automatischen Flow:
ArgoUML $\rightarrow$ JavaDoc+TeXdoclet $\rightarrow$
\LaTeX{} $\rightarrow$ Section \enquote{Klassenbeschreibung} im Entwurf.
\item \href{http://www.iste.uni-stuttgart.de/se-old/links/links-se/entwurfsregeln-fuer-den-objektorientierten-entwurf/principles.html}{Prinzipien für den objektorientierten Entwurf}
Guter Überblicksartikel.
\item \href{http://prinzipien-der-softwaretechnik.blogspot.de/}{Prinzipien Der Softwaretechnik} Blog zum Thema Prinzipien im Software Engineering.
\end{itemize}
\section{Implementierung}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment