1. 1 Java Model-View-Controller - see http://doc.qt.nokia.com/latest/model-view- programming.html#concepts

2. 2 Design Patterns  The hard problem in O-O programming is deciding what objects to have, and what their responsibilities are  Design Patterns describe the higher-level organization of solutions to common problems  They are a current hot topic in O-O design

3. 3 The MVC pattern  MVC stands for Model-View-Controller  The Model includes the data and how it is managed. E.g. the  Client and ArrayList classes in Dating Service project  The City and Hashmap classes in HPAir

4. View & Controller  The View (or a View) is a way of looking at or displaying the model -  E.g the Gui components and textfields in HPAIR  The Controller handles user input and modifications to the view  E.g. The ControlPanel with the listener in ControlPanel in the HPAIR project 4

5. 5 Separation of Roles in MVC

6. 6  Thus, the MVC pattern hinges on a clean separation of objects into one of three categories : 1. models for maintaining data – INCLUDE A MANAGER FOR THE DATA (E.G. an ArrayList OR Hashmap) to store operations on it Advantage of Using MVC

7. MVC  2. views - for displaying all or a portion of the data e.g. TextPanel class in HPAir  3. controllers for handling events that affect the model or view(s). E.g. (ControlPanel in Hpair) 7

8. Advantage of Using MVC  Because of this separation of roles,  multiple views and controllers can interface with the same model.  Even new types of views and controllers that never existed before  can interface with a model without forcing a change in the model design. 8

9. 9 The MVC abstraction can be graphically represented as follows. Event is passed to the controller Controller notifies the View(s) or the Model of changes View gets data from the model Model updates Views when data changes

10. 10 The Model - Summary  The Model is used to 1) manage information and 2) notify observers when that information changes.  It stores : 1) application’s data 2) and defines the logic that manipulates that data.  E.g. In the database of people in a Dating Service, A) clients represent the data and B) the ArrayList class manages the data.   Combined they represent the Model.

11. MODEL  The Model contains a method -  notifyObservers -  that will notify classes when changes that occur to it. 11

12. Model details  A view has a constructor  It takes a reference to a model and registers for updates from it.  There are different opinions on how to manage them  but their separation is undisputed. 12

13. Model  If you need to model two groups of unrelated data and functionality,  you create two separate models. 13

14. Model as an abstraction  A model is meant to serve as an abstraction of some real world process or system  e.g. a queue of people in a security line,  This makes it very easy to use real-world modeling techniques in defining your models. 14

15. 15 MODEL Examples of data for a model – real world objects:  Book  Person  Passenger  Invoice  City  Client

16. 16 A = 50% B = 30% C = 20% The above model contains some data. The views for it could be a spreadsheet display, a bar graph or a pie chart. We use the same model to produce two views.

17. 17 MVC  Ideally, a model has no connection to the user interface used to present and edit it.  For example, if you have a model that represents a person (say you are writing an address book),  you might want to store a birth date.

18. Model and interaction with classes  However, storing a date format string or  how that date is to be presented should be done elsewhere. 18

19. 19 Controller - What it does  A GUI lets the user control what work the program is doing  The Controller is the means by which the user interacts with the application.  HOW??? Did you do this in your current project?

20. CONTROLLER  HOW?  A Controller accepts input from the user and instructs the model and view  to perform actions based on that input.  E.g. the listener class in your DatingService project -  Records that you need to “find by hobby” 20

21. Controller  E.g. a button is pushed and  the controller informs the view to change the its appearance  E.g. if the user clicks the mouse button  or chooses a menu item, 21

22. Controller  the Controller is responsible for determining how the application should respond.  Typically controllers have logic that is specific to an application.-  e.g. what to do when a user pushes a button 22

23. 23 Controller  Controllers make sure the views have access to the model classes they need to display.  E.g. controller classes have a reference to both the view and the model.  Controllers are often the least reusable objects in an application, but that’s acceptable.  You can’t reuse everything!!!!

24. 24 The View  The user has to be able to see, or view, what the program is doing  The View displays what the Controller notifies it to display  The Model is independent of the View but it can provide access methods ( getters) so the view can get information from it.

25. 25 The View  The view should not be responsible for storing the data it is displaying, ---- the model contains the data.  In addition, when the model changes,  the view is told to redraw the image to reflect those changes.

26. 26 Views  The controller layer notifies the view of changes to the model  View objects tend to be reusable,  and provide consistency between applications.

27. View  e.g. the  view will paint people in a line in a bank,  or format a date 27

28. Code Re-USE  We can re- use a panel that draws images  Or the DatingService organization of components  e.g. display results of a search in a JTextArea  A panel of combo boxes 28

29. 29 Combining the Controller and View  Sometimes the Controller and View are combined, especially in small programs  Combining the Controller and View is appropriate if they are very interdependent  The Model should still be independent of everything  Never mix Model code with GUI code!

30. 30 MVC vs SWING  MVC separates the View and the Controller.  Swing does not separate the View and the Controller  At the component level, the components display data and handle events.  This is why your buttons are in the same class as the listener.

31. 31 Swing Combines View and Controller

32. 32 Separation of concerns  As always, you want code independence  The Model should not be contaminated with control code or display code  The Controller should talk to the Model and View by calling methods in the their classes.

33. 33 MVC Pattern

34. 34 The Bouncing Ball Applet  Each click of the Step button advances the ball a small amount  The step number and ball position are displayed in the status line

35. 35 The Ball Applet: Model  The Ball Applet shows a ball bouncing in a window  The Model controls the motion of the ball by keeping track of its location.  To know when to bounce, the Model must know the size of the window  The Model doesn’t need to know anything else about the GUI

36. 36 Model I // contains only information about the ball’s location // Note that it has no reference to the view or controller class Model { final int BALL_SIZE = 20; int xPosition = 0; int yPosition = 0; int xLimit, yLimit; int xDelta = 6; int yDelta = 4; // more...

37. 37 Model II // contains a method to change the location void upDateLocation ( ) { xPosition += xDelta; if (xPosition < 0) { xPosition = 0; xDelta = -xDelta; } // more...

38. 38 Model III if (xPosition >= xLimit) { xPosition = xLimit; xDelta = -xDelta; } // still more... // All it knows is the ball’s location and //keeps track of changes to the location

39. 39 Model IV yPosition += yDelta; if (yPosition = yLimit) { yDelta = -yDelta; yPosition += yDelta; } } // end of makeOneStep method } // end of Model class // All it knows is the ball’s location and //keeps track of changes to the location

40. 40 The Ball Applet: View  The View needs access to the ball’s state - in this case, its x-y location WHICH IS STORED IN THE MODEL.  Therefore it will receive a reference to the model in its constructor  It also needs a reference to the Controller to set the status display on the GUI.  The View doesn’t need to know anything else

41. 41 View I class View extends JPanel { Controller controller; Model model; int stepNumber = 0; // send references of the model and controller to //the constructor View(Controller controller, Model model) public View(Controller controller, Model model) { this. Controller = controller this. Model = model // controller object often not needed }

42. 42 View II // draw the ball WHEN A BUTTON IS PRESSED public void paint (Graphics g) { g.setColor (Color.red); g.fillOval (model.xPosition, model.yPosition, model.BALL_SIZE, model.BALL_SIZE); controller.showStatus ("Step " + (stepNumber++) + ", x = " + model.xPosition + ", y = " + model.yPosition); } // end paint method

43. 43 The Ball Applet: Controller  The Controller interacts with the Model Controller tells the View when it needs to repaint the display  The Controller tells the View when it needs to repaint the display  The Controller doesn’t need to know the inner workings of the Model  The Controller doesn’t need to know the inner workings of the View

44. 44 Controller I public class Controller extends JApplet { Panel buttonPanel; Button stepButton; // set up view and model private Model model ; // set up view and model private View view; // more... // IN AN APPLET THE INIT AND START METHODS ARE //CALLED AUTOMATICALLY ON STARTUP.

45. 45 Controller II public void init () // similar to a constructor in an application { ();// create the panel and button buttonPanel = new Panel ();// create the panel and button stepButton = new Button ("Step"); model = new Model (); // model needs no parameters // send a reference to the model and a reference //to “this” class to the view view = new View (this, model); // Lay out components setLayout (new BorderLayout ()); buttonPanel.add (stepButton); this.add (BorderLayout.SOUTH, buttonPanel); this.add (BorderLayout.CENTER, view);

46. 46 Controller III // Attach actionlistener to the button stepButton.addActionListener (new ActionListener () { public void actionPerformed (ActionEvent event) } // tell the model to update the locationmodel.updateLocation(); // tell the view to redraw the screen IN ITS // PAINT METHOD view.repaint }}); // more...

47. 47 Controller V // set limit and start the drawing public void start ( ) // called automatically { // gets size from the view AND STORES model.xLimit = view.getSize ( ).width - model.BALL_SIZE; model.yLimit = view.getSize ( ).height - model.BALL_SIZE; repaint (); // REDRAWS THE BALL } // end of start method } // end of Controller class

48. Interactions view registers as a listener on the model.  The view registers as a listener on the model. receives notifications  The view receives notifications when the model’s data is altered.  The model is not aware of the view or the controller -- it simply broadcasts changes to it to all interested listeners. 48

49. Interactions  The controller is bound to the view - NEEDS TO REPAINT WHEN BUTTON IS PRESSED  User  User pressing a button invokes a registered listener method(actionPerformed() in the controller class.  The controller is given a reference to 1) the model in its constructor 1) the model in its constructor 2 ) as well a reference to the view 2 ) as well a reference to the view 49

50. Interactions  the model does not have a reference to the view. event-notification methods to notify the controller or the view.  The model uses event-notification methods to notify the controller or the view. change in the data model occurs,  When a change in the data model occurs, property change event  each view is notified by a property change event  and can update itself accordingly. 50

51. 51 Communication between Classes  The model can exist in isolation from its environment, unaware of the view and controller.  E.g., the clients in a JList do not know where they are presented.  A Bidder or Client class does not know how they will be used in the application.

52. 52 Communication between Classes  Each view is associated with a unique controller.  A view has instance variables that are references to the Model(to get information) and Controller( to notify of events). receives the references in its constructor  It receives the references in its constructor -  but it may just have methods that the Controller can call.

53. SUMMARY  Input --> Processing --> Output Model --> Controller --> View  The general principles of MVC are very simple:  "Model is state;  View reacts to input and changes to model;  Controller reacts to view and changes to model;  Controller changes model and view". 53

54. MVC - Roles 54 Model 1. Encapsulates Application State 2. Responds to queries 3.Contains functionality for the state 4. Notifies view or controller of changes State Query View 1. Displays the model 2. Requests updates from model 3.Notifies Controller of user inputs 4. Allows Controller to select view Controller 1. Defines the application behavior 2. Maps user inputs to model updates 3. Selects view for response

55. MVC  The model, view and controller are concepts –  “Generally you use a framework (like Struts)to define model, view and controller and their interactions.  See next slide 55

56.  The Struts Framework is a standard for developing well-architected Web applications. It has the following features:  Open source  Based on the Model-View-Controller (MVC) design paradigm, distinctly separating all three levels: Model: application state View: presentation of data (JSP, HTML) Controller: routing of the application flow  Implements the JSP Model 2 Architecture  Stores application routing information and request mapping in a single core file, struts-config.xml  The Struts Framework, itself, only fills in the View and Controller layers. The Model layer is left to the developer. 56