l10: model-view-controller general application structure. user interface: role, requirements,...

L10: Model-View-Controller• General application structure.• User Interface: Role, Requirements, Problems• Design patterns:

Model – View – Controller, Observer/Observable.

• Implementation problems and strategies in Java and C++.

2

Some domain-specific

code

General Structure

An application generally consists of:

Some user-interface code

Some platform-specific code

3

But What Does It Look Like?

No Separation Partitioned Separated

4

Role of the User Interface

1.To represent the domain model to the user2.To allow the user to control the model.

NOT to be part of the model.

5

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.

6

Potential Problems

1. How does the controller part of the interface ‘know’ when an interaction is requested? (Event-driven programming)

2. What happens if the model is (sometimes) CPU intensive? (Threads)

7

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.

8

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.

9

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.

10

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.

11

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.

12

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.

13

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.

14

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.

15

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.

16

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/).

17

Modelcreates

createsView

createsController

Who creates Model?Version 1: App

App

18

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?

19

createsView

createsController

createsModel

Who creates Model?Version 2: Controller

App

20

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.

21

createsView

createsController

createsModel

Who creates Model?Version 3: View

App

22

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.

23

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: Don’t treat view-

controllers as views — tie the “view” part of the controller to another part of the controller rather than to the model.

24

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.