docs/DesignPatterns

changeset 36:f03413250b39 Ausarbeitung final

some typos and cleanups
author meillo@marmaro.de
date Sat, 11 Aug 2007 22:42:24 +0200
parents 05f432307ba2
children debbd3bf76ce
files detailed-observer.tex
diffstat 1 files changed, 14 insertions(+), 33 deletions(-) [+]
line diff
     1.1 --- a/detailed-observer.tex	Sat Aug 11 15:40:50 2007 +0200
     1.2 +++ b/detailed-observer.tex	Sat Aug 11 22:42:24 2007 +0200
     1.3 @@ -292,38 +292,32 @@
     1.4  
     1.5  
     1.6  
     1.7 -% Daten aus der Beschreibung des Observers von GoF
     1.8 -% in welche Gruppen wird er eingeordnet
     1.9   \subsubsection{Klassifizierung nach GoF}
    1.10  
    1.11     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.12  
    1.13 -  \paragraph{Klassifizierung}
    1.14 +  \paragraph{Klassifizierung:}
    1.15      Verhaltensmuster, objektbasierend
    1.16 -  
    1.17  
    1.18 -  \paragraph{Auch bekannt als}
    1.19 +
    1.20 +  \paragraph{Auch bekannt als:}
    1.21      Publish-Subscribe, Dependents
    1.22 -  
    1.23  
    1.24 -  \paragraph{Zweck}
    1.25 +
    1.26 +  \paragraph{Zweck:}
    1.27      Abhängigkeiten zwischen Objekten erstellen, sodass sich abhängige Objekte ändern, wenn sich das Objekt selbst ändert.
    1.28 -    % todo: besser formulieren
    1.29 -  
    1.30  
    1.31 -  \paragraph{Kurzbeschreibung}
    1.32 +
    1.33 +  \paragraph{Kurzbeschreibung:}
    1.34      Schnittstellen anlegen, damit Abhängigkeiten zwischen Objekten registriert
    1.35      werden können, und um die abhängigen Objekte über Zustandsänderungen zu
    1.36      informieren.
    1.37 -    % todo: Formulierung überdenken
    1.38    
    1.39  
    1.40  
    1.41  
    1.42  
    1.43  \subsection{Beispiele für den Observer in der Praxis}
    1.44 -% Einsatzgebiete (MVC) und RL (Mailingslisten, Ebay-Suchabo)
    1.45 -% nicht aber (Blog + RSS)
    1.46  
    1.47    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.48  
    1.49 @@ -343,8 +337,6 @@
    1.50  
    1.51  
    1.52  
    1.53 -%\subsection{Erweiterungen}
    1.54 -%% Erweiterungen, verbleibende Probleme, Kompromisse beim Design
    1.55  \subsection{Erweiterungen des Patterns}
    1.56  
    1.57    \subsubsection{Ein Observer und mehrere Subjects}
    1.58 @@ -352,33 +344,22 @@
    1.59    
    1.60  
    1.61    \subsubsection{Nur für bestimmte Informationen anmelden}
    1.62 -  Eine weitere kleine Erweiterung ist die Anmeldung am Subject für nur bestimmte Informationen. Dies ist sicher auch eine Ergänzung die unsere Pinnwand verbesser hätte. So wäre es dann möglich gewesen sich nur für Zimmerangebote oder ähnliches anzumelden. So werden auch die unnötigen Updates verringert, was positiv auf die Performance wirken kann.
    1.63 +  Eine weitere kleine Erweiterung ist die Anmeldung am Subject für nur bestimmte Informationen. Dies ist sicher auch eine Ergänzung die unsere Pinnwand verbessert hätte. So wäre es dann möglich gewesen sich nur für Zimmerangebote oder ähnliches anzumelden. Auf diese Weise werden auch die unnötigen Updates verringert, was sich positiv auf die Performance auswirken kann.
    1.64    
    1.65  
    1.66    \subsubsection{ChangeManager}
    1.67 -  Bei komplexen Update-Zusammenhängen ist es empfehlenswert einen ChangeManager zwischen die verschiedenen Subjects und Observers zu stellen. Dieser vermittelt dann zwischen den Beteiligten und koordiniert die Update-Vorgänge. Der ChangeManager ist eine Instanz vom Mediator-Pattern und üblicherweise Singleton, da normalerweise nur einer für alle Observer-Beziehungen verwendet wird.
    1.68 +  Bei komplexen Update-Zusammenhängen ist es empfehlenswert einen ChangeManager zwischen die verschiedenen Subjects und Observers zu stellen. Dieser vermittelt dann unter den Beteiligten und koordiniert die Update-Vorgänge. Der ChangeManager ist eine Instanz vom Mediator-Pattern und üblicherweise Singleton, da normalerweise nur ein ChangeManager für alle Observer-Beziehungen verwendet wird.
    1.69    
    1.70  
    1.71    \subsubsection{Wer ruft notify() auf?}
    1.72 -  Dies kommt stark auf das Programm an. Beide Alternativen haben ihre Vor- und Nachteile:
    1.73 +  Dies kommt stark auf das Programm an. Beide Alternativen haben ihre Vor- und Nachteile.
    1.74  
    1.75 -  \paragraph{Das Subject}
    1.76 +  \paragraph{Das Subject:}
    1.77      Auf diese Weise wird notify() sicher bei jedem setState() aufgerufen, jedoch können die Update-Kosten bei vielen Änderungen in kurzer Zeit sehr hoch werden.
    1.78 -    %\begin{itemize}
    1.79 -    %  \item[+] notify() wird sicher bei jedem setState() aufgerufen
    1.80 -    %  \item[-] hohe Update-Kosten bei Änderungen en-block
    1.81 -    %\end{itemize}
    1.82    
    1.83  
    1.84 -  \paragraph{Der Observer}
    1.85 +  \paragraph{Der Observer:}
    1.86      Hier darf nun der Observer den Aufruf von notify() nicht vergessen, dieser kann jedoch zu einem günstigen Zeitpunkt erfolgen, was sich bei Änderungen en-block positiv auswirkt.
    1.87 -    %\begin{itemize}
    1.88 -    %  \item[+] intelligenter Zeitpunkt des notify()-Aufrufs möglich
    1.89 -    %  \item[-] der Client darf den notify()-Aufruf nicht vergessen
    1.90 -    %\end{itemize}
    1.91 -  
    1.92 -
    1.93 -
    1.94  
    1.95  
    1.96  
    1.97 @@ -393,12 +374,12 @@
    1.98  
    1.99  \section{Zusammenfassung}
   1.100    
   1.101 -  Ich habe in meiner Ausarbeitung bisher ganz bewusst auf Quellcode verzichtet, denn ich wollte Design Pattern einmal von der anderen Seite her erklären. Ich wollte vermitteln weshalb das Observer-Pattern so aufgebaut ist wie es ist. Ich wollte Verständnis für Design Patterns entwickeln und zeigen, dass sie absolut logische Lösungen sind.
   1.102 +  Ich habe in meiner Ausarbeitung bisher ganz bewusst auf Quellcode verzichtet, denn ich wollte Design Patterns einmal von der anderen Seite her erklären. Ich wollte vermitteln weshalb das Observer-Pattern so aufgebaut ist wie es ist. Ich wollte Verständnis für Design Patterns entwickeln und zeigen, dass sie absolut logische Lösungen sind.
   1.103  
   1.104    \paragraph{In drei Sätzen:}
   1.105      \begin{itemize}
   1.106        \item Menschen denken basierend auf der Realität
   1.107 -      \item deshalb Design Patterns auf Realität zurückführen
   1.108 +      \item deshalb Design Patterns auf die Realität zurückführen
   1.109        \item Patterns anwenden weil man es in der Realität auch so machen würde
   1.110      \end{itemize}
   1.111