ModelViewController MVC

1
Model-View-Controller (MVC)
2
Design Patterns

• The hard problem in object-oriented (O-O)
  programming is deciding what objects to have, and
  what their responsibilities are
• Design Patterns describe recommended designs for
  common problems
• Design patterns are a current hot topic in O-O
  design
• The book which started it all is described here
• http//en.citizendium.org/wiki/Design_pattern

3
3 design patterns

• Observer-Observable
• also called Publish-Subscribe
• Singleton
• Model-View-Controller

4
why Model-View-Controller designs?

• in 1870, someone wrote a novel
• there is a 2002 audio-tape version of it
• there is a 1926 hardback edition of it
• there is a 2005 paperback edition of it
• in 1987, a film was made of it
• one novel but 4 different ways of presenting it

5
Model-View-Controller pattern goals

• there are often many ways to present the same
  problem
• requirements on how a problem is displayed tend
  to change (i.e., experimentation goes on)
• the MVC design tries to separate the code that
  represents the problem from the code that
  presents the problem to the user
• this allows the presentation part to be change
  more easily
• this pattern arose because management has so
  often demanded that programmers modify
  presentation
• without the correct design, thats hard
• with this pattern, it becomes much easier

6
the three roles

• the Model contains data that represents the
  problem
• the Controller responds to user actions by
  telling the Model how to change
• the View displays the current state of the Model
  to the user

7
how do we design it?

• the Model is a class that represents the actual
  problem being solved
• it has private fields, and provides accessor
  (getter and setter) methods
• the Model should always be a separate class
• if using a GUI
• the listeners collectively are the Controller
• the displayed components are the View
• the Controller and View are thus a little bit
  interdependent

8
the View may not be the only possible View

• the user has to be able to see, or view, what the
  program is doing
• a View is one way of showing what the Model is
  doing
• a View is a passive observer it should not
  change the model
• the Model should know nothing about any View
• but it can provide getters for use by Views or by
  the Controller
• a View and a Controller should not communicate
  directly with each other

9
Combining 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 always be independent
• Never mix Model code with GUI code!
• why?
• ANSWER you may be required to change the View
• if you keep View and Model separate, changing the
  View will be relatively simple

10
Separation of concerns
Singleton?

• How to set up an MVC design
• instantiate the Model first, and only once
• Model contains data (instance fields)
  representing the problem domain
• Model provides setters and getters for the
  underlying data
• instantiate the View
• the View might consist of GUI components such as
  buttons or lists
• configure the View to update automatically when
  the underlying data in the Model changes
• instantiate the Controller
• add listeners for anything the user can do
• make each listener change the Model as appropriate

push or pullmethods
11
The Reverser program

• In this program we combine the Controller and the
  View (indeed, its hard to separate them)
• The Model, which does the computation (reversing
  the string) is in a separate class

12
ReverserGUI.java

• public class ReverserGUI extends JFrame
• private ReverserModel model new
  ReverserModel()
• private JTextField text new JTextField(30)
• public static void main(String args)
• new ReverserGUI().run()
• // run method and button listener on next
  slide
• // end class

13
The run method and the listener
private void run()
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)
setLayout(new GridLayout(2, 1))
getContentPane().add(text) JButton
button new JButton("Reverse")
getContentPane().add(button)
button.addActionListener( new Do() )
pack() setVisible(true) // end
run public class Do implements
ActionListener public void
actionPerformed(ActionEvent arg0)
String s model.reverse( text.getText() )
text.setText(s) // end
inner class
14
The model

• public class ReverserModel public String
  reverse(String s) StringBuilder builder
  new StringBuilder(s)
  builder.reverse() return
  builder.toString()

15
how can a View automatically update?

• use a timer and periodically have the View poll
  the Model
• bad in terms of performance
• requires appropriate timer interval frequent
  enough polling to display changes seamlessly
• use the Observer-Observable pattern between the
  Model and any GUI components that need to be
  updated
• once you do this, you can forget about the View
• but, you have to learn the Observer-Observable
  pattern

16
Observer and Observable

• java.util provides an Observer interface and an
  Observable class
• A class that inherits from Observable is an
  object that can be observed
• A class that implements Observer is notified
  when an object that it is observing announces a
  change
• An analogy
• An Observable is like a Button
• An Observer is like a Listener
• You have to attach a Listener to a Button
• Another analogy
• An Observable is like a bulletin board
• An Observer is like someone who reads the
  bulletin board

17
Observable

• An Observable is an object that can be observed
• When an Observable wants the world to know
  about what it has done, it executes
• setChanged()
• notifyObservers() / or / notifyObservers(arg)
• The arg can be any object
• The Observable doesnt know or care who is
  looking

18
connecting them

• you have attach an Observer to the Observable
  with
• myObservable.addObserver(myObserver)
• An Observer is notified when an object that it
  is observing announces a change

19
Observer

• a class that implements Observer
• public void update(Observable obs, Object arg)
• the above method will be invoked whenever the
  Observable object changes the information being
  watched
• the first argument is a reference to the
  observable object itself
• the second argument may be null

20
Key points

• the Model does the business logic
• it should be I/O free
• communication with the Model is via methods
• this approach gives maximum flexibility in how
  the model is used
• the Controller provides input (control) to the
  Model
• a View displays what is going on in the model
• It should never display what should be going on
  in the model
• For example, if you ask to save a file, the View
  shouldnt itself tell you that the file has been
  savedit should tell you what the model reports
• in small programs, the Controller and View may be
  combined
• they are usually a little bit inter-dependent

21
the end of this PowerPoint file
Hooray!