Model-View-ControllerDesign PatternsThe MVC patternThe ModelThe ControllerThe ViewCombining Controller and ViewSeparation of concernsThe “Reverser” programReverserGUI.javaThe create methodThe modelThe Bouncing Ball AppletThe Ball Applet: ModelObserver and ObservableObservableObserverSample CRC index cardModelModel IModel IIModel IIIModel IVModel (repeated)The Ball Applet: ViewViewView IView IIView IIIView (repeated)The Ball Applet: ControllerControllerController IController IIController IIIController IVController VController (repeated)Key pointsThe EndJan 14, 2019Model-View-Controller2Design PatternsThe hard problem in O-O programming is deciding what objects to have, and what their responsibilities areDesign Patterns describe the higher-level organization of solutions to common problemsDesign patterns are a major topic in O-O design3The MVC patternMVC stands for Model-View-ControllerThe Model is the actual internal representationThe View (or a View) is a way of looking at or displaying the modelThe Controller provides for user input and modificationThese three components are usually implemented as separate classes4The ModelMost programs are supposed to do work, not just be “another pretty face”but there are some exceptionsuseful programs existed long before GUIsThe Model is the part that does the work--it models the actual problem being solvedThe Model should be independent of both the Controller and the ViewBut it provides services (methods) for them to useIndependence gives flexibility, robustness5The ControllerThe Controller decides what the model is to doOften, the user is put in control by means of a GUIin this case, the GUI and the Controller are often the sameThe Controller and the Model can almost always be separated (what to do versus how to do it)The design of the Controller depends on the ModelThe Model should not depend on the Controller6The ViewTypically, the user has to be able to see, or view, what the program is doingThe View shows what the Model is doingThe View is a passive observer; it should not affect the modelThe Model should be independent of the View, but (but it can provide access methods)The View should not display what the Controller thinks is happening7Combining Controller and ViewSometimes the Controller and View are combined, especially in small programsCombining the Controller and View is appropriate if they are very interdependentThe Model should still be independentNever mix Model code with GUI code!8Separation of concernsAs always, you want code independenceThe Model should not be contaminated with control code or display codeThe View should represent the Model as it really is, not some remembered statusThe Controller should talk to the Model and View, not manipulate themThe Controller can set variables that the Model and View can read9The “Reverser” programIn this program we combine the Controller and the View (indeed, it’s hard to separate them)The Model, which does the computation (reversing the string), we put in a separate class10ReverserGUI.javaA bunch of import statements, then...public class ReverserGUI extends JFrame { ReverserModel model = new ReverserModel(); JTextField text = new JTextField(30); JButton button = new JButton("Reverse"); public static void main(String[] args) { ReverserGUI gui = new ReverserGUI(); gui.create(); gui.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); } ... create()...}11The create method private void create() { setLayout(new GridLayout(2, 1)) getContentPane().add(text) getContentPane().add(button); button.addActionListener(new ActionListener() public void actionPerformed(ActionEvent arg0) String s = text.getText() s = model.reverse(s) text.setText(s) }) pack(); setVisible(true) }12The modelpublic class ReverserModel { public String reverse(String s) { StringBuilder builder = new StringBuilder(s); builder.reverse(); return builder.toString(); }}13The Bouncing Ball AppletEach click of the Step button advances the ball a small amountThe step number and ball position are displayed in the status line14The Ball Applet: ModelThe Ball Applet shows a ball bouncing in a windowThe Model controls the motion of the ballIn this example, the Model must know the size of the windowso it knows when the ball should be made to bounceThe Model doesn’t need to know anything else about the GUI15Observer and Observablejava.util provides an Observer interface and an Observable classAn Observable is an object that can be “observed”An Observer is “notified” when an object that it is observing announces a changeHere’s an analogy:An Observable is like a ButtonAn Observer is like a ListenerYou have to “attach” a Listener to a ButtonAnother analogy:An Observable is like a bulletin boardAn Observer is like someone who reads the bulletin board16ObservableAn Observable is an object that can be “observed”An Observer is “notified” when an object that it is observing announces a changeWhen an Observable wants the “world” to know about what it has done, it executes:setChanged();notifyObservers(); /* or */ notifyObservers(arg);The arg can be any objectThe Observable doesn’t know or care “who is looking”But you have attach an Observer to the Observable with:myObservable.addObserver(myObserver);This is best done in the controller class – not in the model class!17ObserverObserver is an interfaceAn Observer implementspublic void update(Observable obs, Object arg)This method is invoked whenever an Observable that it is “listening to” does an addNotify() or addNotify(arg)The obs argument is a reference to the observable object itselfIf the Observable did addNotify(), the arg is null18Sample CRC index cardClass NameResponsibilities. . .. . .. . .Collaborators. . .. . .. . .19ModelModelSet initial positionMove one stepNo collaborators.......but provide access methods to allow view to see what is going on20Model Iimport java.util.Observable;class Model extends Observable { final int BALL_SIZE = 20; int xPosition = 0; int yPosition = 0; int xLimit, yLimit; int xDelta = 6; int yDelta = 4; // more...21Model II void
View Full Document
Unlocking...