docs/DesignPatterns

diff detailed-observer.tex @ 34:b2cefbd90180

some redesign; new content for summary and appendix
author meillo@marmaro.de
date Sat, 11 Aug 2007 12:49:00 +0200
parents 97b57d24fd7b
children 05f432307ba2
line diff
     1.1 --- a/detailed-observer.tex	Fri Aug 10 22:15:51 2007 +0200
     1.2 +++ b/detailed-observer.tex	Sat Aug 11 12:49:00 2007 +0200
     1.3 @@ -1,5 +1,5 @@
     1.4  % @file
     1.5 -% @brief   Referat DesignPatterns `Observer'
     1.6 +% @brief   Ausarbeitung DesignPatterns `Observer'
     1.7  % @author  markus schnalke <meillo@marmaro.de>
     1.8  % @since   2007-05-30
     1.9  
    1.10 @@ -28,7 +28,7 @@
    1.11  \begin{titlepage}
    1.12    \title{Observer-Pattern}
    1.13    \author{Markus Schnalke}
    1.14 -  \date{2007-07-04}
    1.15 +  \date{2007-08-11}
    1.16  
    1.17  
    1.18    \thispagestyle{empty}
    1.19 @@ -362,18 +362,20 @@
    1.20    \subsubsection{Wer ruft notify() auf?}
    1.21    Dies kommt stark auf das Programm an. Beide Alternativen haben ihre Vor- und Nachteile:
    1.22  
    1.23 -    \paragraph{Das Subject}
    1.24 -    \begin{itemize}
    1.25 -      \item[+] notify() wird sicher bei jedem setState() aufgerufen
    1.26 -      \item[-] hohe Update-Kosten bei Änderungen en-block
    1.27 -    \end{itemize}
    1.28 +  \paragraph{Das Subject}
    1.29 +    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.30 +    %\begin{itemize}
    1.31 +    %  \item[+] notify() wird sicher bei jedem setState() aufgerufen
    1.32 +    %  \item[-] hohe Update-Kosten bei Änderungen en-block
    1.33 +    %\end{itemize}
    1.34    
    1.35  
    1.36 -    \paragraph{Der Observer}
    1.37 -    \begin{itemize}
    1.38 -      \item[+] intelligenter Zeitpunkt des notify()-Aufrufs möglich
    1.39 -      \item[-] der Client darf den notify()-Aufruf nicht vergessen
    1.40 -    \end{itemize}
    1.41 +  \paragraph{Der Observer}
    1.42 +    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.43 +    %\begin{itemize}
    1.44 +    %  \item[+] intelligenter Zeitpunkt des notify()-Aufrufs möglich
    1.45 +    %  \item[-] der Client darf den notify()-Aufruf nicht vergessen
    1.46 +    %\end{itemize}
    1.47    
    1.48  
    1.49  
    1.50 @@ -390,19 +392,8 @@
    1.51  \newpage
    1.52  
    1.53  \section{Zusammenfassung}
    1.54 - %\textbf{Zusammenfassend}
    1.55    
    1.56 -  Ich habe in meiner Ausarbeitung bisher ganz bewusst auf Quellcode verzichtet, denn 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.57 -
    1.58 -  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:
    1.59 -
    1.60 -  \begin{quote}
    1.61 -    \textbf{ Implementierungen sind Schall und Rauch,\\ 
    1.62 -    Konzepte dagegen bleiben bestehen!  }
    1.63 -  \end{quote}
    1.64 -
    1.65 -  Aus diesem Grund will ich mich mit Quelltext auf dieses Beispiel im Anhang beschränken. Dennoch finde ich es wichtig, doch zumindest eine Beispiel-Implementierung vorzeigen zu können, da Quellcode sehr aussagekräftig sein kann. In jeden Fall wird er meine sonstigen Ausführungen gut abrunden.
    1.66 -
    1.67 +  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.68  
    1.69    \paragraph{In drei Sätzen:}
    1.70      \begin{itemize}
    1.71 @@ -412,6 +403,26 @@
    1.72      \end{itemize}
    1.73  
    1.74  
    1.75 +  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:
    1.76 +
    1.77 +  \begin{quote}
    1.78 +    \textbf{Implementierungen sind Schall und Rauch,\\ 
    1.79 +    Konzepte dagegen bleiben bestehen!  }
    1.80 +  \end{quote}
    1.81 +
    1.82 +  Design Patterns sind Konzepte --- Programmiersprachen kommen und gehen, Design Patterns überleben. Wenn man also in die Zukunft investieren möchte, dann sollte man sich Design Patterns aneignen, denn diese Investition ist risikofrei und zudem hoch rentabel!
    1.83 +
    1.84 +  \vspace{10ex}
    1.85 +
    1.86 +  \textit{Ich wollte euch von dieser Erkenntnis überzeugen. Ich wollte euch für Patterns begeistern. Ich hoffe das ist mir gelungen  :-) } 
    1.87 +
    1.88 +  \begin{flushright}
    1.89 +    markus schnalke
    1.90 +  \end{flushright}
    1.91 +
    1.92 +
    1.93 +
    1.94 +
    1.95  
    1.96  
    1.97  
    1.98 @@ -421,10 +432,16 @@
    1.99  
   1.100  \section{Beispiel-Implementierung}
   1.101  
   1.102 +  Ich möchte mich mit Quelltext auf dieses Beispiel im Anhang beschränken. Dennoch finde ich es wichtig, zumindest eine Beispiel-Implementierung vorzeigen zu können, da Quellcode sehr aussagekräftig sein kann. In jeden Fall wird er meine sonstigen Ausführungen gut abrunden. Hier also eine Realisierung in Java:
   1.103 +
   1.104 +  \vspace{4ex}
   1.105 +
   1.106    {\scriptsize
   1.107      \lstinputlisting[language=java]{code/observer-example.java}
   1.108    }
   1.109 -  \flushright{ \tiny Quellcode von http://java2s.com }
   1.110 +  \begin{flushright}
   1.111 +    {\tiny Quellcode von http://java2s.com}
   1.112 +  \end{flushright}
   1.113  
   1.114  
   1.115