Unformatted text preview:

9. Model/View/Controller and ObserverInteractor PatternNeed to share UI codeViews and ControllersObserver PatternMVC ImplementationObservable/Observer InterfacesObservable ImplementationObserver ImplementationsConsole ControllerControl FlowFacadesNon-View ObserverVariations in Observer/Observable CommunicationSummaryCOMP 114Prasun Dewan1 9. Model/View/Controller and ObserverThe principle we have used so far to implement interactive applications has been to keep computation anduser-interface code in separate classes. All user-interface code, however, was put in one class. We will seehere the rationale for the principle and also how we can refine it to support both reusability and multiple, concurrent and consistent user interfaces manipulating the same object. The technique we will use can beabstracted into the general Model/View/Controller pattern. This pattern is built on top of the Observer pattern, which has applications beyond user interfaces.Interactor PatternConsider the following figure: a) Console based I/O (c) Console based I/O and Message-based Output (b) Console based input and message based outputFigure 1 Alternative user interfaces for the same object1  Copyright Prasun Dewan, 2000. 1It shows three different user interfaces to manipulate a counter. Each user interface allows input of a value to add to the counter and displays the updated value to the user. Figure 1(a) uses the console window for input and output. It displays the initial value of the counter. It allows the user to enter the (positive or negative) values to be added to the counter, and after the input value, it shows the current value of the counter. The user interface of Figure 1(b) retains the mechanism to change the counter but used an alternative way to display the counter value. Instead of printing it in the console window, it creates a new “message” window on the screen that shows the value. Figure 1(c) shows that it is possible to combine elements of the other two user interfaces. It also retains console-based input, but displays the counter in both the console window and the message window.If we were told to implement only the interface of Figure 1(a), we would probably write the following code:public class ConsoleUI { static int counter = 0; public static void main(String[] args) {while (true) { int nextInput = readInt(); if (nextInput == 0) return; counter += nextInput; System.out.println("Counter: " + counter);} } //readInt() ….}If only Figure 1(b) was to be implemented, we would similarly write:package main;public class ConsoleUI { static int counter = 0; public static void main(String[] args) {while (true) { int nextInput = readInt(); if (nextInput == 0) return; counter += nextInput; System.out.println("Counter: " + counter);} } //readInt() ….}However, this is far from the ideal solution if we want to reuse code among the three interfaces. For one, it does not allow the code manipulating the counter to be shared. We can create a special object that allows a counter to be incremented or decremented by an arbitrary value and provides a method to access the current counter value. The following class describes this object:package models;public class ACounter implements Counter {int counter = 0;public void add (int amount) {2counter += amount;}public int getValue() {return counter;}}Thus, we are now following the principle of keeping user interface and computation code separate. This principle is captured by the following model/interactor pattern. InteractorModelArbitrary UI unaware methodsComputation codeUI CodeFigure 2 Interactor PatternHere we refer to the class implementing the user interface code as the interactor and the object it manipulates as the model. Like the MVC pattern we see before, it is not a pattern identified by the patterns book. The reason probably is that it puts almost no constraint on the communication between an interactor and a model. An interactor can call arbitrary methods in the model. The only constraint imposedis that the model methods contain no user interface code. This pattern allows us to create a new user interfaces for an object without changing existing model and user interface code. The figure below shows how the pattern can be applied to create the three user interfaces. A separate class. AConsoleUI, AMixedUI, and AMultipleUI, implement the user interface of Figure 1(a), 1(b) and 1(c) respectively. Each class is independent of the other main classes and dependent only on the interface of the model.Figure 3 Three interactor classes using the same model classThe code for AConsoleUI is given below:package interactors;3AConsoleUIAMixedUICounterAMultipleUIAConsoleUIAMixedUICounterCounterAMultipleUIInteractorInteractorInteractorInteractorInteractorInteractorpublic class AConsoleUI implements ConsoleUI { public void edit (Counter counter) {while (true) { int nextInput = readInt(); if (nextInput == 0) return; counter.add(nextInput); System.out.println("Counter: " + counter.getValue());} } // readInt ….}The implementation of the console I/O creates the model, displays its initial value to the user, and then executes a loop that calls the add method of the model with each input value and then displays the new counter. The code to read an integer value is not shown here.The main class now simply composes the interactor with the model:public static main (String args[]) (new AConsoleUI()).edit (new ACounter());}Similarly, the interactor for Figure 1(b) is:package interactors;public class AMixedUI implements ConsoleUI { public void edit (Counter counter) {while (true) { int nextInput = readInt(); if (nextInput == 0) return; counter.add(nextInput); JOptionPane.showMessageDialog(null, "Counter: " + counter.getValue());} }}Instead of appending to the console, it uses the JOption class of the Swing toolkit to display the value in anew message window.The interactor for the combined user interface combines the output of the other two interactors:package interactors;public class AMultipleUI implements ConsoleUI { public void edit (Counter counter) {while (true) { int nextInput = readInt(); if (nextInput == 0) return; counter.add(nextInput); System.out.println("Counter: " + counter.getValue()); JOptionPane.showMessageDialog(null, "Counter: " + counter.getValue());}4}}Need to share UI


View Full Document

UNC-Chapel Hill COMP 114 - Model/View/Controller and Observer

Download Model/View/Controller and Observer
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Model/View/Controller and Observer and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Model/View/Controller and Observer 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?