COSC346 User Interfaces Lecture 21: ModelViewController

1
COSC346 User InterfacesLecture 21
Model-View-Controller
2
Announcement

• Assignment due Friday _at_ 16
• No labs or tutes this week -- work on your
  assignment.

3
Overview

• General application structure.
• Design patterns
• Model View Controller,
• Observer/Observable.
• Implementation problems and strategies.

4
General Structure
An application generally consists of
5
But What Does It Look Like?
6
Role of the User Interface

• 1. To represent the domain model to the user
• 2. To allow the user to control the model.
• NOT to be part of the model.

7
User Interface Requirements

• Represent objects of interest.
• Provide alternative representations.
• Allow control via different mechanisms.
• Implies that the user interface must be
  loosely-coupled to the application model.

8
Potential Problems

• How does the controller part of the interface
  know when an interaction has been requested?
• Event-driven programming
• What happens if the model is (some-times) CPU
  intensive?
• Threads

9
Decoupling

• A flexible, loosely-coupled arrangement is
  appropriate for this separation of application
  model and user interface.
• The Model-View-Controller design pattern derived
  from Smalltalk is a useful construct.

10
Design Patterns (1)

• Generally, descriptions of communicating objects
  and classes that are customized to solve a
  general design problem in a particular context.
  -- Design Patterns, p3.

11
Design Patterns (2)

• The intention is not necessarily to reuse the
  code that implements a design pattern wholesale,
  but rather to understand the solution mechanism
  so well that writing new implementations of the
  pattern can be done efficiently.

12
Model-View-Controller

• A design pattern consisting of a triad of
  classes
• Model - the application object,
• View - the screen presentation of the object,
• Controller - defines the way the user interface
  reacts to input.
• Classes are decoupled by defining a subscribe/
  notify protocol.
• Multiple views and controllers can be defined.

13
Model-View-Controller
Relies on an Observer mechanism (another design
pattern) to connect the classes. A View must
ensure that it accurately and completely reflects
the current state of the Model. The Model
notifies all Views that depend on it. The
Controller modifies the state of the object
through its programming interface in response to
user actions.
14
Advantages

• Multiple views can be added to an object.
• Multiple control mechanisms can be implemented.
• Presentation and control of the model can be
  changed without rewriting the model itself.

15
Why Is This Useful?

• It allows application-specific code to be
  localized.
• It allows the view to be different from the
  model.
• It allows multiple differing views of the same
  model.
• It allows the mechanism for control to be
  separate from both the view and the model.

16
MVC in Java

• Java.util.Observable - a base class that
  incorporates the observer mechanism.
• Java.util.Observer - an interface that can be
  implemented which notices when objects that it is
  observing change state.
• The Swing user interface classes use the
  Model-View-Controller pattern as a basis.

17
Implementation in Java

• Model classes extend Observable.
• View classes extend Applet and implement
  Observer.
• Each View must
• implement the update() method and
• be added to the Model instance via addObserver().
  
• When the Model calls notifyObservers(), the
  update() method of all observing Views will be
  called.

18
Implementation in C

• No explicit code for Observer/Observable
  mechanisms.
• View and Controller interact with the Model via
  normal Get and Set functions.
• Some libraries allow callback functions, e.g.
  OpenGL and qt.
• For an alternative view, see outerface
  (http//www.outerface.com/).

19
Who creates Model?Version 1 App
20
Version 1 App

• Model really is model and nothing else.
• App is responsible for registering any number of
  observers/controllers.
• M V C components can all be controlled
  directly from App (good???).
• Have to create M, then V, then register, then
  update M.
• Make model constructor responsible for adding
  views?

21
Who creates Model?Version 2 Controller
22
Version 2 Controller

• Controller automatically gets a reference to the
  model.
• Becomes responsible for initiating all state
  changes to model (including creation).
• Has to surrender a reference to the model to let
  the view be added as an observer.
• Ends up being responsible for adding observers to
  model (not ideal).
• Implies only one controller.

23
Who creates Model?Version 3 View
24
Version 3 View

• View responsible for adding itself as observer to
  model.
• Implies only one view.
• Multiple views might share reference to model
  rather than each create one.

25
When View is Controller

• For example, sliders and text fields.
• Situation View has to become Observable as well
  as Observer.
• Problem Multiple inheritance.
• Possible Solution Dont treat view-controllers
  as views tie the view part of the controller
  to another part of the controller rather than to
  the model.

26
Summary

• Flexible decoupling of user interface and
  application is essential.
• Model-View-Controller is a useful design pattern.
• Java is amenable to MVC implementation through
  the Observer/Observable classes.
• Complete decoupling is not always possible, or
  may lead to inelegant code.

27
Next Lecture
User Interface Models