Transcript
DESIGN PATTERNS
Decorator, Proxy, Iterator and Observer (MVC)
Dr Simon Spacey
B.Sc. Hons. (York), M.Sc. (Lancaster), M.B.A. (Cass), J.L.P. (Keio), D.E.A. (Montpellier), D.CSC. (Cambridge), D.I.U. (Imperial), Ph.D. (Imperial)
© Simon Spacey.
20/05/2013
<1>
What are Design Patterns? ¡ Design Patterns: ¡ Are Ways to Solve OOL Implementation Problems... ¡ ... that often have Trivially Obvious “Imperative” Solutions ¡ Popularised by the 1995 Book by Erich Gamma et al. ¡ Are often Supported by Libraries in OOLs
¡ Design Patterns Include: ¡ Creational:
Factory, Abstract Factory, Builder Prototype, Singleton
¡ Structural:
Adapter (DAO), Bridge, Composite, Decorator, Façade, Flyweight, Proxy
E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addison Wesley, 1995
¡ Behavioural: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer (MVC), State, Strategy, Template, Visitor © Simon Spacey.
18/04/2013
<2>
Decorator: Overview ¡ The Decorator Pattern Wraps One or More of a Classes Methods and Optionally Adds New Methods: Similar to an Adapter, ¡ Useful as a filter to log or change functionality
Except Adapter Changes the Interface
¡ Notes: ¡ Is a Concrete Class with Associated Relations Embedded at Run-time
¡ Positives and Negatives: ü Supports Cross-Cutting Concerns (e.g. Adding Pre/Post-Logging to Subclasses) ü Solves Inability to call ((Cast)o).method() in Java (ok in C, C++, Objective-C) ü Allows Recursive Nesting (does not change the Superclass’s interface) ü Dynamic Runtime Instance Wrapping ✘ Extra Layer of Programming Indirection (Code Complication)! !
© Simon Spacey.
18/04/2013
<3>
Decorator: UML 1
Base Class +doSomething()
Associated/ Has-A relation meaning externally managed
Decorator
ConcreteChild
-wrapped : Base Class +doSomething()
+doSomething()
1
// Pre-Processing wrapped.doSomething(); // Post-Processing
An Example UML Diagram Illustrating the Decorator Design Pattern
© Simon Spacey.
18/04/2013
<4>
Decorator: Example ¡ Before:
¡ After:
!
!
...!
...!
!
! !
! !
! "! // Initialises the Pacman Pills, Power Pills and Ghosts! public void initialise() {!
Wraps the eat() method to beep when pill eaten*
!
"! // Initialises the Pacman Pills, Power Pills and Ghosts! public void initialise() {! !
Pill pill = new Pill1(); // finalize()=default! !
Pill pill = new BeepPill(new Pill1()); // finalize()=beep! !
...!
...!
!
! !
! displayList.add(pill.newInstance(x, y));!
displayList.add(pill.newInstance(x, y));!
!
! !
! ...!
...!
!
! }! !
}! !
...!
newInstance()
also Decorated to return a BeepPill
...! !
* There is no guarantee delete will call finalize() except if manually call System.gc() in Java. Hence we could need say an eat() method to remove a pill from the display list.
© Simon Spacey.
18/04/2013
<5>
Proxy: Overview ¡ The Proxy Design Pattern is a Surrogate for Another Object: ¡ The Proxy can be used to allow Late/Demand Based or Remote Instantiation! Similar to Decorator except for “Intent”: Late Binding and Remote Instantiation and Controlling Access
¡ Notes:
¡ The Proxy can Execute Some Code Locally and Only Call the Real Object for Large Fns
¡ Positives and Negatives: ü Can Delay Objects Instantiation (Virtual Proxy)! ü Supports Object Migration (Remote Proxy) ü Can add Access Control (e.g. Smart Pointers, COW, Protection and Synchronization) ✘ Extra Layer of Programming Indirection (Code Complication)
© Simon Spacey.
18/04/2013
<6>
Proxy: UML A Dependence in Some Sense
Client
«interface» Interface +doSomething()
Real
Proxy +doSomething()
«uses»
+doSomething()
An Example UML Diagram Illustrating the Proxy Design Pattern
© Simon Spacey.
18/04/2013
<7>
Proxy: Example ¡ Before:
¡ After:
!
!
import java.sql.*;! ! ...!
! ...!
!
! //*** Simple Adapter between JDBC and the Application! public class DAO implements DAOInterface {!
//*** Simple Virtual Proxy for DAO! public class DAOProxy implements DAOInterface {!
!
!
!
!
private Connection c = null; // initialised by...! private Statement s = null; // ... instance...! private RecordSet r = null; // ... constructor!
private DAO dao = null;! ! ! !
...! public synchronized unsigned int getHighScore() {! r = s.executeQuery("SELECT MAX(score) FROM scores");! return (r.next() ? r.getInt(1) : 0);! }! ...!
...! public synchronized unsigned int getHighScore() {! if(dao==null) dao = new DAO(); // late init of c, s and r! return dao.getHighScore();! }! ...!
}!
}!
!
! ...!
...!
!
© Simon Spacey.
18/04/2013
<8>
Iterator: Overview ¡ The Iterator Design Pattern Provides a Consistent Interface for Iterating over Disparate Collections: ¡ Can use the same code to iterate over Link Lists, Skip Lists, Arrays, Trees etc…!
¡ Notes: ¡ Each Collection must Return a Specific Iterator with Appropriate Internal Knowledge
¡ Positives and Negatives: ü Provides a Standard Interface for Iterating over Disparate Collections ü Can have Multiple Iterators at Different Points in one Collection ü Can have Different Iteration Algorithms (e.g. Forward and Backward) ✘ Collection Modification may need to be Synchronized with Active Iterators (!Robust) ✘ Having an Iterator Does not Enforce Consistent Collection Access Interfaces © Simon Spacey.
18/04/2013
<9>
Iterator: UML A Collection Instance Could Be a Self Iterator
«interface» Iterable +iterator() : Iterator
+iterator() : Iterator
Associations with TreeIterator not shown
© Simon Spacey.
18/04/2013
+hasNext() : bool +next() : Object +remove()
LinkedList
TreeList
«interface» Iterator
+iterator() : Iterator 0..1
1
ListIterator
TreeIterator
+hasNext() : bool +next() : Object +remove()
+hasNext() : bool +next() : Object +remove()
An Example UML Diagram Illustrating the Iterator Design Pattern
<10>
Iterator: Example ¡ Before:
¡ After:
...! public class DisplayList {! private DisplayItem first private DisplayItem last ...! }! ...!
import java.util.Iterator;! ...! public class DisplayList implements Iterable, Iterator {! private DisplayListLink first = null;! private DisplayListLink last = null;! private DisplayListLink current = null; // iterator state ! ...! // Our simple non-reentrant self Iterator initialiser! public Iterator iterator() {! this.current = first; ! return (Iterator)this;! }! ...! This is the “foreach” loop }! form in Java – works for ...!
!
!
= null;! = null;!
! ! ! ! ! ! ! public class GUIEngine {! ...! // Triggers each of the displayList elements to draw! public void draw() {! DisplayItem item = displayList.first();! while(item!=null) {! item.draw();! item = item.next;! }! }! ...! }! ...!
© Simon Spacey.
18/04/2013
<11>
!
java.util.Iterator
!
implementations and arrays
!
public class GUIEngine {! ...! // Triggers each of the displayList elements to draw! public void draw() {! for(Object item : displayList) ((DisplayItem)item).draw();! }! ...! Cast here because not }! used “Generics” ...!
Observer (MVC): Overview ¡ The Observer Pattern Notifies a Set of Registered Observers on an Object’s State Change or the Occurrence of an Event: C Callbacks in OOP ¡ In MVC the Model (M) can notify Viewers (V) on Changes Due to Controller (C) Events
¡ Notes: ¡ Generally, the Observer is Only Notified and has to Query the Modified State It Self
¡ Positives and Negatives: ü Allows Consistent Viewers on Same Data (Many-to-One Dependency) ü Allows Abstract Coupling (Observers Need Not be Statically Related) ü Observers may be able to Absorb Notifications (c.f. JavaScript Event Bubbling) ✘ Observers may be Notified on Inappropriate Changes (Need Subject Lists) ✘ Changes to Model need to be Atomic/ Consistent (While Notify may Block Updates) © Simon Spacey.
18/04/2013
<12>
Observer (MVC): UML «interface» Observer
Observable +addObserver() +deleteObserver() +notifyObservers()
+update() Associations with Model not shown
Model
Controler 1
0..*
+setData()
View1 1
0..*
+update()
An Example UML Diagram Illustrating the Observer (MVC) Design Pattern
© Simon Spacey.
18/04/2013
<13>
View2 +update()
Observer (MVC): Example ¡ Before:
¡ After:
! import android.view.*;! ! ...!
! import android.view.*;! import java.util.*; ...!
!
"// has Observer implementation!
!
!
public class GUIEngine extends View {! public class GUIEngine extends View {!
!
!
private float x; "// access through getters...! private float y; "// ... to stop write access! private Observable xyObservers = new Observable(); ! ...!
...! ! ! !
! // Sends the current touched location to the GameEngine! @Override! public boolean onTouchEvent(MotionEvent ev) {! ...! gameEngine.setDirection(x, y);! ...! }! ...!
// Sends the current touched location to all Observers! @Override! public boolean onTouchEvent(MotionEvent ev) {! ...! xyObservers.notifyObservers();! ...! }! Now we can have say a ...!
swipeable control panel too
}!
!
! public class GameEngine implements Observer {! ...! public void setDirection(float x, float y) {...}! ...! }!
public class GameEngine implements Observer {! ...! public void update(Observable o, Object arg) {...}! ...! }!
!
}!
!©
Simon Spacey.
18/04/2013
<14>
Summary ¡ Design Patterns: ¡ Are Ways to Solve OOL Implementation Problems... ¡ ... that often have Trivially Obvious “Imperative” Solutions ¡ Popularised by the 1995 Book by Erich Gamma et al. ¡ Are often Supported by Libraries in OOLs
¡ Design Patterns Include the: ¡ Decorator Pattern
– A Filter that can Add Functionality by Wrapping an Object!
¡ Proxy Pattern
– Delays Instantiation or Allows Remote Invocation
¡ Iterator Pattern
– Standard Interface to Iterate over a Collection
¡ Observer (MVC) Pattern – Model Notifies One or More Viewers on State Change © Simon Spacey.
18/04/2013
<15>
