docs/DesignPatterns

changeset 30:8bdd4e54885e

added content
author meillo@marmaro.de
date Sat, 04 Aug 2007 16:42:40 +0200
parents f3b4061ec3b4
children f567cec0d755
files detailed-observer.tex
diffstat 1 files changed, 41 insertions(+), 39 deletions(-) [+]
line diff
     1.1 --- a/detailed-observer.tex	Sun Jul 08 20:49:06 2007 +0200
     1.2 +++ b/detailed-observer.tex	Sat Aug 04 16:42:40 2007 +0200
     1.3 @@ -208,24 +208,20 @@
     1.4  
     1.5  \subsection{Zusammenfassung des Beispiels}
     1.6  
     1.7 -  \paragraph{Pinnwand + Sekretärin + Benachrichtigung}
     1.8 -    \begin{itemize}
     1.9 -      \item Man kann neue Zettel anpinnen lassen
    1.10 -      \item Man kann sich als Interessierter anmelden (und auch abmelden)
    1.11 -      \item Interessierte werden bei Änderungen der Pinnwand benachrichtigt
    1.12 -      \item Sie können dann zur Pinnwand gehen und sie sich anschauen
    1.13 -    \end{itemize}
    1.14 -  
    1.15 +  Wir haben nun eine Lösung die die meisten Probleme unserer Situation löst. Ich möchte hier die Funktionsweise nochmals aufzählen:
    1.16 +
    1.17 +  \begin{itemize}
    1.18 +    \item Man kann neue Zettel anpinnen lassen
    1.19 +    \item Man kann sich als Interessierter anmelden (und auch abmelden)
    1.20 +    \item Interessierte werden bei Änderungen der Pinnwand benachrichtigt
    1.21 +    \item Sie können dann zur Pinnwand gehen und sie sich anschauen
    1.22 +  \end{itemize}
    1.23  
    1.24    
    1.25 +  Sind jetzt alle Anforderungen abgedeckt? Ist die geschaffene Struktur zufriedenstellend? Welche Wünsche sind noch offen? Was fehlt?
    1.26  
    1.27 -  \paragraph{Eure Meinung?}
    1.28 -    \begin{itemize}
    1.29 -      \item Ist diese Struktur zufriedenstellend?
    1.30 -      \item Erfüllt sie alle Anforderungen?
    1.31 -      \item Was fehlt?
    1.32 -    \end{itemize}
    1.33 -  
    1.34 +  Es gibt natürlich weitere Anforderungen/Wünsche die über das jetzige Modell hinausgehen. Auf einige der verbreitendsten Erweiterungen des Observer-Modells werde ich weiter unten noch eingehen.
    1.35 +
    1.36  
    1.37  
    1.38  
    1.39 @@ -251,26 +247,30 @@
    1.40  \newpage
    1.41  \section{Das Pattern}
    1.42  
    1.43 +  Nun haben wir uns eine Lösung für unser Problem erarbeitet und der nächste Schritt ist es ein allgemein gültiges Lösungsmodell zu erstellen. Ein solches Modell wird ``Pattern'' genannt.
    1.44 +
    1.45  
    1.46  \subsection{Überleitung}
    1.47 +  
    1.48 +  Um unsere Lösung in das Pattern zu überführen bedarf es ein paar anderer Bezeichnungen:
    1.49  
    1.50 -  \paragraph{Neue Namen}
    1.51 -    \begin{itemize}
    1.52 -      \item Pinnwand-Sekretärin-Einheit $\rightarrow$ ``Subject''
    1.53 -      \item Die Zettel auf der Pinnwand $\rightarrow$ ``subjectState''
    1.54 -      \item Interessenten $\rightarrow$ ``Observers''
    1.55 -    \end{itemize}
    1.56 +  \begin{itemize}
    1.57 +    \item Pinnwand-Sekretärin-Einheit $\rightarrow$ ``Subject''
    1.58 +    \item Die Zettel auf der Pinnwand $\rightarrow$ ``subjectState''
    1.59 +    \item Interessenten $\rightarrow$ ``Observers''
    1.60 +  \end{itemize}
    1.61  
    1.62 -  \paragraph{Schnittstellen}
    1.63 -    Die Fähigkeiten der Pinnwand/Sekretärin und Interessenten sind ihre ``Interfaces''.
    1.64  
    1.65 -    (vgl: taub, minimale Fähigkeiten, leserliche Schrift, ...)
    1.66 +  Beim Programmieren sind besonders Interfaces (also Schnittstellen) wichtig. Diese entsprechen den Fähigkeiten die Pinnwand/Sekretärin und Interessenten haben oder anbieten. Dies wären zum Beispiel, dass Interessenten nicht taub sein dürfen, lesen und zur Pinnwand hingehen können müssen. Oder auch die leserliche Schrift der Sekretärin. (Siehe dazu auch die Erarbeitung der Pinnwand-Sekretärin.)
    1.67    
    1.68  
    1.69  
    1.70  
    1.71  \subsection{UML-Diagramme}
    1.72 - \subsubsection{Struktur-Diagramm des Observers}
    1.73 +
    1.74 +  Um das Pattern darzustellen bieten sich UML-Diagramme an.
    1.75 +
    1.76 +  \subsubsection{Struktur-Diagramm des Observers}
    1.77  
    1.78    \begin{figure}[hbt]
    1.79      \centering
    1.80 @@ -280,7 +280,7 @@
    1.81  
    1.82  
    1.83  
    1.84 - \subsubsection{Interaktions-Diagramm des Observers}
    1.85 +  \subsubsection{Interaktions-Diagramm des Observers}
    1.86    \begin{figure}[hbt]
    1.87      \centering
    1.88      \includegraphics[width=12cm]{pics/observer-interaction_big.png}
    1.89 @@ -288,12 +288,17 @@
    1.90    \end{figure}
    1.91  
    1.92  
    1.93 +  Wer den ersten Teil der Ausarbeitung verstanden hat und UML kann, sollte hier keine Probleme haben die Diagramme zu verstehen --- es ist quasi das Gleiche, nur in einer anderen Darstellungsform.
    1.94 +
    1.95 +
    1.96  
    1.97  
    1.98  % Daten aus der Beschreibung des Observers von GoF
    1.99  % in welche Gruppen wird er eingeordnet
   1.100   \subsubsection{Klassifizierung nach GoF}
   1.101  
   1.102 +   Die ``Gang of Four'' (sie formulierten die ersten Design-Patterns für die Informatik) habe ein einheitliches Schema zu ihrer Klassifizierung erstellt. Anhand diesem ist der Observer folgendermaßen einzuordnen:
   1.103 +
   1.104    \paragraph{Klassifizierung}
   1.105      Verhaltensmuster, objektbasierend
   1.106    
   1.107 @@ -321,20 +326,17 @@
   1.108  % Einsatzgebiete (MVC) und RL (Mailingslisten, Ebay-Suchabo)
   1.109  % nicht aber (Blog + RSS)
   1.110  
   1.111 -  \paragraph{Beispiele}
   1.112 -    \begin{itemize}
   1.113 -      \item Observer ist sehr verbreitet
   1.114 -      \item v.a. MVC (Model = Subject; View = Observer)
   1.115 -      \item Mailinglisten
   1.116 -      \item Ebay Such-Abo
   1.117 -    \end{itemize}
   1.118 -  
   1.119 +  Wo ist das Observer-Pattern nun im täglichen Leben anzutreffen? Natürlich ist hier das Leben in der digitalen Welt gemeint, schließlich geht es uns ja um ein Design-Pattern für die Programmierung.
   1.120  
   1.121 -  \paragraph{Aber}
   1.122 -    \begin{itemize}
   1.123 -      \item nicht Blog mit RSS-Feed!
   1.124 -    \end{itemize}
   1.125 -  
   1.126 +  Zuerst einmal ist anzuführen, dass der Observer ein sehr verbreitetes Design-Pattern ist, das recht häufig bei passenden Problemstellungen eingesetzt wird.
   1.127 +
   1.128 +  Primär wäre das alles was mit Model-View-Controller (kurz: MVC) zusammenhängt. MVC wird vor allem für grafische Oberflächen eingesetzt. Dabei fungiert das Model als Subject und die View als Observer. Der Controller ist eher von untergeordneter Bedeutung. (MVC ist übrigens ein Architektur-Pattern.) 
   1.129 +
   1.130 +  Aber auch Mailinglisten und Such-Abos (wie bei Ebay) sind optimalerweise nach dem Observer-Pattern implementiert.
   1.131 +
   1.132 +
   1.133 +  \textbf{Kein} Beispiel für das Observer-Pattern ist aber der Weblog mit RSS-Feed! Denn hier findet kein Abonnement-Vorgang statt, der Client (Observer)  meldet sich nicht bei der Website (Subject) an, und bekommt auch keine Änderungsinformationen zugeschickt. Stattdessen ruft der Client nur Informationen ab, die die Website ständig zur Verfügung stellt. (vgl. Pinnwand ohne Sekretärin)
   1.134 +
   1.135  
   1.136  
   1.137