\documentclass{article} \usepackage{ulem} \usepackage{graphicx} \usepackage{hyperref} \pagestyle{headings} \begin{document} \part{Design Patterns} 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 \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 ... \item ... 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} 

require\_once 'DB.php';

\$type = 'mysql';
\$options = array(...);
\$dbh = \&DB::connect(\$type, \$options);
\subsubsection{Implementing Abstract Factory} 

    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;
    \}
\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} 

    function \&singleton()
    \{
        static \$registry;

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

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

    /**
     * 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;
    \}
\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} 

    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);
        \}
    \}
\subsubsection{Implementing Observer: Observer} 

    function update(\&\$subject)
    \{
        // Do what needs to be done.
    \}
\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 ... numerous \item Phrame \item MVCnPHP \end{itemize} \section{Some Resources} \begin{itemize} \item The Portland Pattern Repository (the original wiki) \item php|architect \item phpPatterns.com (not updated recently) \end{itemize} \end{document}