docs/DesignPatterns: detailed-observer.tex comparison

comparison detailed-observer.tex @ 36:f03413250b39 Ausarbeitung final

some typos and cleanups

author	meillo@marmaro.de
date	Sat, 11 Aug 2007 22:42:24 +0200
parents	05f432307ba2
children

comparison

equal deleted inserted replaced

-:05f432307ba2
+:f03413250b39
 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.
-% Daten aus der Beschreibung des Observers von GoF
-% in welche Gruppen wird er eingeordnet
 \subsubsection{Klassifizierung nach GoF}
 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:
-\paragraph{Klassifizierung}
+\paragraph{Klassifizierung:}
 Verhaltensmuster, objektbasierend
-\paragraph{Auch bekannt als}
+\paragraph{Auch bekannt als:}
 Publish-Subscribe, Dependents
-\paragraph{Zweck}
+\paragraph{Zweck:}
 Abhängigkeiten zwischen Objekten erstellen, sodass sich abhängige Objekte ändern, wenn sich das Objekt selbst ändert.
-% todo: besser formulieren
+\paragraph{Kurzbeschreibung:}
-\paragraph{Kurzbeschreibung}
 Schnittstellen anlegen, damit Abhängigkeiten zwischen Objekten registriert
 werden können, und um die abhängigen Objekte über Zustandsänderungen zu
 informieren.
-% todo: Formulierung überdenken
 \subsection{Beispiele für den Observer in der Praxis}
-% Einsatzgebiete (MVC) und RL (Mailingslisten, Ebay-Suchabo)
-% nicht aber (Blog + RSS)
 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.
 Zuerst einmal ist anzuführen, dass der Observer ein sehr verbreitetes Design-Pattern ist, das recht häufig bei passenden Problemstellungen eingesetzt wird.
-%\subsection{Erweiterungen}
-%% Erweiterungen, verbleibende Probleme, Kompromisse beim Design
 \subsection{Erweiterungen des Patterns}
 \subsubsection{Ein Observer und mehrere Subjects}
 Oft ist es nicht nur ein einziges Subject, das beobachtet werden soll. Damit ein Observer mehrere Subjects beobachten kann, muss er den Namen des Subjects mitsenden. So kann festgestellt werden welches Subject betroffen ist.
 \subsubsection{Nur für bestimmte Informationen anmelden}
-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.
+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.
 \subsubsection{ChangeManager}
-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.
+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.
 \subsubsection{Wer ruft notify() auf?}
-Dies kommt stark auf das Programm an. Beide Alternativen haben ihre Vor- und Nachteile:
+Dies kommt stark auf das Programm an. Beide Alternativen haben ihre Vor- und Nachteile.
-\paragraph{Das Subject}
+\paragraph{Das Subject:}
 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.
-%\begin{itemize}
-%  \item[+] notify() wird sicher bei jedem setState() aufgerufen
-%  \item[-] hohe Update-Kosten bei Änderungen en-block
+\paragraph{Der Observer:}
-%\end{itemize}
-\paragraph{Der Observer}
 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.
-%\begin{itemize}
-%  \item[+] intelligenter Zeitpunkt des notify()-Aufrufs möglich
-%  \item[-] der Client darf den notify()-Aufruf nicht vergessen
-%\end{itemize}
 \newpage
 \section{Zusammenfassung}
-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.
+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.
 \paragraph{In drei Sätzen:}
 \begin{itemize}
 \item Menschen denken basierend auf der Realität
-\item deshalb Design Patterns auf Realität zurückführen
+\item deshalb Design Patterns auf die Realität zurückführen
 \item Patterns anwenden weil man es in der Realität auch so machen würde
 \end{itemize}
 Design Patterns sind dabei Modelle wie Quellcode aufgebaut werden sollte. Sie sind kein Code --- sie beschreiben nur wie Code sein sollte. Das ist auch ganz gut so, denn:

Mercurial > docs > DesignPatterns

comparison detailed-observer.tex @ 36:f03413250b39 Ausarbeitung final