Design Patterns Model – View – Controller

1. Design PatternsModel – View – Controller

2. 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. 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. Observable Observer +addObserver(Observer)+deleteObserver(Observer)+notifyObservers(Object)#hasChanged() : boolean#setChanged() +update(Observable, Object) AccountView SummaryView BankAccount +update(Observable, Object) +update(Observable, Object) +widthdraw(double) : long+deposit(double) : long+getBalance() : double Observer Class Diagram

5. Transactions Happen! Controller BankAccount AccountView SummaryView deposit() setChanged() notifyObservers() update() getBalance() update() getBalance()

6. 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. Architecture Diagram Model business logic Set State GetState Update Event ChangeView View model representation Controller user interaction UserActions

8. 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. 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!