Lecture Model View Controller s/w architecture AND general tips on structuring classes

Structuring your classes.. When you create your various classes in an application, you want to: Promote reusability (e.g. panels for OK/Cancel buttons might be used in several screens) Minimise code maintenance when something changes (e.g. dB structure, new GUI device ) Maintain as much flexibility as possible

Model View controller MVC is a common s/w architecture pattern used for interactive applications (i.e. applications that have a Graphical User i/f) Model = classes that deal with storing and using data View = classes that deal with the GUI part Controller = (non graphical) classes that bridge the View and the Model

Model Model = classes that deal with storing and using data –If data structure(s) or rules change.. Just change these classes –Can have multiple different GUIs using the same model E.g. calculator functions add/substract etc Different GUIs (standard web, accessible web etc) Aside: Data may be persistent or not persistent – how to deal with persistent?

View = classes that deal with the GUI part –If the GUI changes, don’t (necessarily) need to change the model or control classes E.g. change borders of buttons View

Controller = (non graphical) classes that bridge the View and the Model –Kept separate E.g. control (driver) class with ‘main’ method to run an application Listener classes that trigger behaviour Generally.. Consists of everything that is not the GUI or not directly storing/using data Controller

Example Counter – this screen displays a number in them middle which you can move up by 1 or down by 1 using the buttons A simple Counter 25 Up Down Frame Buttons Label Title

MVC - Counter example Classes needed? For View bit.. –Frame? With some buttons “on” it? Label? Title? For Model bit.. - What “data” is involved? What can be done to it? Is there a dB involved? For Controller bit.. What’s needed apart from GUI and doing the model part? At LEAST 3 classes…

Counter Example For View bit.. –How many classes? Are any “bits” reusable? If not, put in a single class. Otherwise separate out.. For Model bit.. - Need to be able to add, subtract, and store the “data”.. A class that has methods to do this For Controller bit.. - Need a control class to run the counter.. What else?

Counter Example – possible class structure that is MVC compliant For View bit.. –Class for the counterPanel –Class for the counter Frame For Model bit.. - class that has methods to do the increment (up), decrement () etc. i.e. that “does” the data part. For Controller bit.. - class for the listener (that extends actionListener0 - class to run the overall application = 5 classes in total Q: How will they link together? E.g. how do I get the GUI class(es) to “call” the model class methods to add/decrement the counters?

To use MVC in your own GUI applications Often easiest to start with the View first… What class(es) deal just with the visual part (GUI)? = View classes What classes are then needed to deal with manipulating/storing data? = Model What’s left? What control classes are need to respond to things that happen in the view?

Another example A Calculator –What’s the View part? –What’s the model part? –What’s the control part?

Other things.. Giant all purpose class for everything – wrong! –Hard to maintain –Nothing reusable Decide which “parts” might be reusable –E.g. button panels, listener behaviour, –This gives a clue as to how to break out classes Pick out the definable “things” in your app e.g. circle, square – suggests separate classes Keep MVC as a guiding principle but…

Finally As with any design –There is no single “right” answer to how you break your app into classes –But you should design in advance, rather than just letting your code wander along in a single class or two… MVC is one s/w architecture –Some techniques we’ve seen contradict it E.g. implementing listeners directly in the GUI code Anonymous listeners – embedded against the GUI component – has its own advantages.. These approaches have their own merits.. –Be aware of the trade offs.