1. Design Patterns Model – View – Controller

2. Copyright © 2001 DeLorme 28 November 2001 History ► A framework pattern for reusable applications. ► Depends on the Observer pattern. ► First developed by Xerox PARC for Smalltalk-80. ► Used by the Application Kit system in NeXTstep. ► Used by the Cocoa APIs for Apple’s OS X. ► Recommended structural framework pattern in J2EE. ► I have used this pattern for nearly ten years.

3. Copyright © 2001 DeLorme 28 November 2001 Observer Pattern ► Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. ► Used to decouple the subject from the observer, since the subject needs little information to notify the observer. ► Can result in excessive notifications.

4. Copyright © 2001 DeLorme 28 November 2001 Observer Class Diagram Observable +addObserver(Observer) +deleteObserver(Observer) +notifyObservers(Object) #hasChanged() : boolean #setChanged() Observer +update(Observable, Object) AccountView +update(Observable, Object) BankAccount +widthdraw(double) : long +deposit(double) : long +getBalance() : double SummaryView +update(Observable, Object)

5. Copyright © 2001 DeLorme 28 November 2001 Transactions Happen! ControllerBankAccountAccountViewSummaryView deposit() setChanged() notifyObservers() update() getBalance()

6. Copyright © 2001 DeLorme 28 November 2001 Observer Rocks! ► The Observer pattern allowed the BankAccount class to notify multiple views without minimal information. ► Observers can register themselves with their Subjects. No strings attached! ► Transactions would cause this design to collapse under spurious notifications!

7. Copyright © 2001 DeLorme 28 November 2001 Architecture Diagram View model representation Model business logic Controller user interaction UpdateEvent User Actions Change View SetState Get State

8. Copyright © 2001 DeLorme 28 November 2001 Advantages ► Separation between the data layer and the interface is the key:  The view is easily replaced or expanded.  Model data changes are reflected in all interfaces because all views are Observers.  Better scalability since UI and application logic are separated.  Distribution over a network is greatly simplified.

9. Copyright © 2001 DeLorme 28 November 2001 Problems ► Problems of translation:  Business logic bleeds into the Controller.  Observer pattern is non-obvious for EJBs. See EJBObserver by Greg Comeau. ► Problems of the pattern:  Excessive coupling between the Model and View and the Model and Controller.  Frozen interfaces are hard to manage!