\documentclass{article}
\usepackage{ulem}
\pagestyle{headings}
\begin{document}
\part{ Design Patterns}
\tableofcontents

TODO: add more from the kongress2002-design\_patterns presentation

\section{ What are design patterns?}
\begin{quote}
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."? Christopher Alexander, talking about buildings and towns\newline
\end{quote}

\begin{itemize}
\item{Many common programming problems}
\item{They've been solved over and over again}
\item{Recognize which problems are common}
\item{Name them to create a common vocabulary}
\item{Patterns are blueprints}
\item{They are meant to be modified}
\item{Not all suspension bridges are the same}
\end{itemize}
\section{ What do patterns not do?}
\begin{itemize}
\item{Patterns are not rules}
\item{Patterns are not implementations!}
\end{itemize}
\section{ When to use them}
\begin{itemize}
\item{When the Problem they solve is a problem you have \ldots}
\item{\ldots and when the Consequences are acceptable}
\item{Solve problems you have, not problems you think you might have}
\end{itemize}
\section{ Common Patterns}
\begin{itemize}
\item{Abstract Factory}
\item{Singleton}
\item{Observer}
\item{Model/View/Controller}
\end{itemize}
\subsection{ Abstract Factory}
\begin{itemize}
\item{Provides an interface for creating one of a family of objects without specifying that object's concrete class name.}
\item{Example: DB::connect()}
\end{itemize}
\begin{verbatim}

require_once 'DB.php';

$type = 'mysql';
$options = array(...);
$dbh = &DB::connect($type, $options);
\end{verbatim}

\subsubsection{ Implementing Abstract Factory}
\begin{verbatim}

    function &factory($type)
    {
        @include_once("DB/${type}.php");

        $classname = "DB_${type}";

        if (!class_exists($classname)) {
            return PEAR::raiseError(null, DB_ERROR_NOT_FOUND,
                                    null, null, null, 'DB_Error', true);
        }

        return $obj =& new $classname;
    } 
\end{verbatim}

\subsection{ Singleton}
\begin{itemize}
\item{Ensures that there is only ever one instance of a class.}
\item{Can only be implemented as a suggestion in PHP4}
\end{itemize}
\subsubsection{ Implementing Singleton}
\begin{verbatim}

    function &singleton()
    {
        static $registry;

        if (!isset($registry)) {
            $registry = new Registry();
        }

        return $registry;
    }
\end{verbatim}

\subsubsection{ Implementing Singleton in PHP5}
PHP5's improved object model allows a better singleton implementation:

\begin{verbatim}

    /**
     * The one instance.
     */
    static private $instance = false;

    /**
     * Make the constructor private.
     */
    private function __construct() {}

    /**
     * Use this static method to get at the one instance.
     */
    static public function singleton()
    {
        if (!self::$instance) {
            self::$instance = new Singleton();
        }
        return self::$instance;
    }
\end{verbatim}

\subsection{ Observer}
\begin{itemize}
\item{Also called Subject-Observer, Listener, or Publish-Subscribe}
\item{Let an arbitrary number of objects react to state changes}
\end{itemize}
\subsubsection{ Implementing Observer: Subject}
\begin{verbatim}

    function attach(&$observer)
    {
        $this->_observers[$observer->getId()] =& $observer;
    }

    function detach(&$observer)
    {
        unset($this->_observers[$observer->getId()]);
    }

    function notify()
    {
        foreach ($this->_observers as &$observer) {
            $observer->update($this);
        }
    }
\end{verbatim}

\subsubsection{ Implementing Observer: Observer}
\begin{verbatim}

    function update(&$subject)
    {
        // Do what needs to be done.
    }
\end{verbatim}

\subsection{ Model/View/Controller}
\begin{itemize}
\item{MVC is a specialized Observer pattern, with Composite and Strategy completing the picture}
\item{Observer describes how Views and Models interact}
\item{Composite lets Views be made up of other Views}
\item{Strategy lets Views use different Controllers}
\end{itemize}
\subsubsection{ MVC: Model/View}
\begin{itemize}
\item{Think of structured HTML as a Model, and CSS as a View}
\item{Goal is to completely separate data and logic from presentation}
\item{Allows redesigns or new views (different stylesheet) without changing the Model}
\end{itemize}
\subsubsection{ MVC: View Compositing}
\begin{itemize}
\item{When Smalltalk-80 introduced MVC it had a CompositeView}
\item{The Composite pattern solves the problem of wanting to treat groups of objects like individual objects}
\end{itemize}
\subsubsection{ MVC: View/Controller}
\begin{itemize}
\item{The Controller decides how a View handles user input}
\item{Think of a command line interface, web interface, and web services as potential Controllers}
\item{Controllers take user input and give them to both Views and Models as appropriate}
\end{itemize}
\section{ PHP Implementations}
\begin{itemize}
\item{http://www.google.com/search?q=php+mvc\footnote{http://www.google.com/search?q=php+mvc} \ldots numerous}
\item{Phrame\footnote{http://phrame.sourceforge.net/}}
\item{MVCnPHP\footnote{http://www.tonybibbs.com/index.php?topic=MVCnPHP}}
\end{itemize}
\section{ Some Resources}
\begin{itemize}
\item{The Portland Pattern Repository\footnote{http://c2.com/ppr/} (the original wiki)}
\item{php|architect\footnote{http://www.phparchitect.com/}}
\item{phpPatterns.com\footnote{http://www.phppatterns.com/} (not updated recently)}
\end{itemize}
\end{document}
