Added some design pattern content

Lectures/L16_MISContinued/MISContinued.tex

@@ -95,6 +95,24 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Emphasis}
+\begin{itemize}
+\item Math notation
+\item Modules with external interaction (environment variables)
+\item Types of modules
+\item Abstract Data Types
+\item Qualities of an interface
+\item Design patterns
+\begin{itemize}
+  \item Adapter (Wrapper) pattern
+  \item Strategy pattern
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 % \begin{frame}
 % \frametitle{Nonfunctional Requirements}
 % \begin{itemize}
@@ -1085,6 +1103,217 @@ where $a$, $b$ and $c$ are suitable constants
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Design Patterns}
+
+\begin{itemize}
+
+\item Christopher Alexander (1977, buildings/towns):
+\begin{itemize}
+\item ``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.''
+\end{itemize}
+\item Design reuse (intended for OO)
+\item Solution for recurring problems
+\item Transferring knowledge from expert to novice
+%\item Provides language for communicating about design
+\item A design pattern is a recurring structure of communicating components that
+  solves a general design problem within a particular context
+\item Design patterns consist of multiple modules, but they do not constitute an
+  entire system architecture
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Adapter Design Pattern}
+
+\includegraphics[scale=0.7]{500px-AdapterPatternForWiki.jpg}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Adapter UML Diagram}
+% client uses target (follows targets interface)
+% client, adapter and adaptee appear as in previous slide
+\medskip
+\includegraphics[scale=0.7]{adapter_clip.pdf}
+
+\href{https://en.wikipedia.org/wiki/Adapter_pattern}
+{Wikipedia entry}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{SimUDuck Example}
+
+\bigskip
+
+\includegraphics[scale=0.74]{StratPat-SimUDuck.pdf}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Adding a Fly Method}
+
+\bigskip
+
+\includegraphics[scale=0.85]{StratPat-FlyMethod.pdf}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Rubber Duck Problem}
+
+\includegraphics[scale=0.7]{StratPat-RubberDuck.pdf}
+
+\structure{How to stop rubber ducks from flying?} %override to do nothing
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Rubber Duck Problem Continued}
+
+\bi
+\item Solve problem by overriding the fly() method to do nothing
+\item Not a good solution - think of the potential maintenance problems if we
+  add wooden decoys, which cannot fly, or quack - what about different quacks?
+\ei
+
+Which of the following are disadvantages of using inheritance to provide Duck
+behaviour?
+
+\begin{enumerate}[A.]
+\item Some code is duplicated across subclasses
+\item Runtime behaviour changes are difficult
+\item Difficult to gain knowledge of all duck behaviours
+\item Changes can unintentionally affect other ducks
+\item All of the above %answer
+\end{enumerate}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{How About an Interface?}
+
+\includegraphics[scale=0.75]{StratPat-Interface.pdf}
+
+Disadvantages of interface?
+
+\begin{enumerate}[A.]
+\item Maintenance nightmare - the different options for fly and quack are
+  duplicated everywhere %answer
+\item Ducks that have fly and quack are clearly shown
+\item All of the above
+\end{enumerate}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Information Hiding}
+
+How can the principle of information hiding help us?
+
+\begin{enumerate}[A.]
+\item Identify the aspects of the application that are likely to change and
+  separate them from what is unlikely to change
+\item Provide a means for part of the system to vary independently of the other
+  parts
+\item Prevent the program's user from knowing which ducks can fly and/or quack
+\item A and B %answer
+\item A, B and C
+\end{enumerate}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Separate Out Changeable Parts (Likely Changes)}
+
+\bigskip
+
+\includegraphics[scale=0.85]{StratPat-DuckBehaviours.pdf}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Implementing the Duck Behaviours}
+
+\bigskip
+
+\includegraphics[scale=0.66]{StratPat-ImpDuckBehaviours.pdf}
+
+\bi
+\item Program to an interface not an implementation (interface in the sense we have
+used it for MISes, not just a Java interface)
+\item Other modules can use these behaviours too
+\item Can add new behaviours without touching the original Duck class
+\ei
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{The Big Picture}
+
+\bigskip
+
+\includegraphics[scale=0.66]{StratPat-BigPicture.pdf}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Often Favour Composition over Inheritance}
+
+\bi
+\item Composition provides a ``has a'' relationship, as opposed to an ``is a''
+  relationship
+\item Composition provides greater flexibility
+\item Composition allows changing behaviour at runtime
+\item Many languages (like Java) do not allow multiple inheritance, but can have
+  multiple compositions
+\ei
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Strategy Pattern}
+
+Defines a family of algorithms, encapsulates each one, and makes them
+interchangeable.  Strategy lets the algorithm vary independently from the
+clients that use it.
+
+\includegraphics[scale=0.6]{Strategy1.png}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{frame}[allowframebreaks]
 \frametitle{References}