Post on 18-Jan-2018
description
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.