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 user 2.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 (

17 Model creates View creates Controller 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 creates View creates Controller creates Model 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 creates View creates Controller creates Model 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.