SADI Model View Controller (MVC) Revision
RMIT University © 2019 School of Science
1
Implementing a GUI based system
• One of the primary goals of implementing a quality* interactive (GUI based) system is to separate the user interface code from the application code.
• Benefits:
–User Interface can be more easily modified (portability,
accessibility etc.)
–Application code can change without affecting the interface (e.g. text file based data is replaced by DBMS)
–Project can be more easily split across teams (requires good management, communication)
–Provides a logical basis for modularising the application
* See next slide
RMIT University © 2019 School of Science 2
Software Quality
Comprehensible (easy to understand code) Maintainable (easy to repair, change, maintain) Extensible (easy to extend/add new features) Reusable (easy to reuse components in isolation) Reliable (fault free, does not fail or crash)
Secure (more independent of software structure)
Efficient (good performance with minimal resource usage i.e. performance/resource utilisation)
can be a trade-off with the other factors above
RMIT University © 2019 School of Science 3
Model View Controller
One technique for modularising an interactive system is the Model View Controller approach:
–Originally conceived for the Smalltalk environment –Can be applied to any UI based system (even when UI
is non graphical!)
–Used internally within AWT/Swing (less so in Android unfortunately!)
–Can be implemented easily and effectively in Java with communication between Packages, Classes and Listeners
–Increases cohesion while managing coupling in a structured way
RMIT University © 2019 School of Science 4
Model View Controller
RMIT University © 2019 School of Science 5
Model View Controller
Model: contains application code such as:
– data structures I/O routines
– accessor methods calculations etc.
View: the representation of the data i.e. how it is presented to the user
– (may be devices other than simple display terminal e.g. accessibility devices for disabled persons)
– multiple views of the same data (e.g. a spreadsheet has cell and chart views) Controller: handles user interaction and mediates between the
Model (data) and The View (representation) including data conversion
– e.g user drags mouse in a drawing program. The controller modifies the series of points or vectors (data structures) in the model as the mouse is moved (user interaction) and instructs the view to redraw the data in the model (alternatively the model may automatically instruct it’s registered views to redraw its data – example of Observer pattern [Design Patterns, Gamma et al. 1995])
• Consider Microsoft Excel as an Example
RMIT University © 2019 School of Science 6
Model View Controller
The Model, View and Controller are treated as separate modules
–may be classes or packages depending upon their complexity
–a system may have multiple views, controllers and models
–multiple views are quite common but not required
–nearly always a separate controller for each view (for cohesion) although these are often implemented as inner classes in Java and thus not entirely separate
–multiple models are usually used when there exist groups of independent program data
RMIT University © 2019 School of Science
Model-View Controller Pattern
• Problem – Ensure any changes to data (model) is reflected by all observers (views)
7
• Solution – separate problem into three separatecomponents
• Model provides the data and determines the current state of application
• View determines the appearance
• Controller interprets the events (mouse,
keystroke)
• Commonly used in Web applications:
view2
DI
CR
data
Grade num HD 23 DI 32 CR 49
.. ..
Model
HD
view1
CR DI
HD
View
Model -> View -> Controller ->
Database or xml
HTML page
Script handling the events
Controller
RMIT University © 2019
School of Science
8
MVC Events Sequence
• User performs action (using keyboard, mouse) and controller is passed the relevant data
• Controller may simply update view or specify changes to model
• Model may notify all attached views if it has changed
• View may query model to retrieve data and updates display
RMIT University © 2019
Benefits of MVC
Model
View 2 View 1
Controller
School of Science 9
• Results in less coupling between functionality and presentation
– Easier to maintain (cohesive modules)
– Separates roles clearly e.g. DB programmer, application programmer, usability expert, graphic design and GUI programmer etc.
• Ensures all views are consistent with current model
• Allows different types of views for same document
• Allows different user interface technologies for the same application
– e.g. Java desktop app, web app, android app etc.
• Provides a well known pattern or structure
•RMIT University © 2019 •School of Science •10
Inner Classes
Version 1.1 of the JDK introduced the notion of inner classes
–often used with event handling
–(potentially) simplify the relationship between event
sources and listeners
Non-static (standard) inner classes:
–have direct access to the implementation of their enclosing class (including private attributes and methods)
–are automatically initialised with a reference to the instance of the outer class that created it [ usually the reference is invisible and implicit e.g. SomeMethodCall() but can be made explicit with EnclosingClassName.this.SomeMethodCall() ]
RMIT University © 2019 School of Science 11
Inner Classes
• Inner classes may be named or anonymous
• Static inner classes are similar to C++ nested classes (no reference to outer class)
• Can be hidden from other classes in a package (private)
• See sadi.topic5.inner.fundamentals.*;
• The next five slides show five variations on the relationship between event sources (ThreeDButton in
this case) and listeners and shows how inner classes can be helpful in expressing this relationship
RMIT University © 2019 School of Science 12
Separate Listener (Event Source)
class ThreeDButton {
public ThreeDButton
{
ThreeDButtonListener threeDlistener=new ThreeDButtonListener(); addMouseListener(threeDlistener); addMouseMotionListener(threeDlistener);
}
public void paintBorderInset()
{
// … }
public void paintBorderRaised()
{
// … }
}
RMIT University © 2019 School of Science 13
Separate Listener
class ThreeDButtonListener extends MouseAdapter
implements MouseMotionListener {
public void mousePressed(MouseEvent event) {
ThreeDButton button = (ThreeDButton)event.getSource(); button.paintBorderInset();
}
public void mouseClicked(MouseEvent event) {
ThreeDButton button = (ThreeDButton)event.getSource(); button.paintBorderRaised();
}
public void mouseReleased(MouseEvent event) {
ThreeDButton button = (ThreeDButton)event.getSource(); button.paintBorderRaised();
}
public void mouseDragged(MouseEvent event) {
ThreeDButton button = (ThreeDButton)event.getSource();
if(button.contains(event.getX(), event.getY())) { if(button.getState() == ThreeDButton.BORDER_RAISED)
}
else {
} }
button.paintBorderInset();
if(button.getState() == ThreeDButton.BORDER_INSET) button.paintBorderRaised();
public void mouseMoved(MouseEvent event) { } }
RMIT University © 2019 School of Science 14
Separate Listener
• Advantages:
–self contained and cohesive
–can have multiple sources use a single instance of a listener if desirable
–listener is not ‘hard coded’ to the source
=> source can be modified independently of listener
• Disadvantages:
–must call getSource() in every method that needs
access to the event source and cast is fragile
–may be cumbersome to create separate classes for very small one line operations (not really true with good IDE)
RMIT University © 2019 School of Science 15
Separate Listener Alternative (Modified Event Source)
class ThreeDButton {
public ThreeDButton
{
ThreeDButtonListener ThreeDlistener=new ThreeDButtonListener(this);
addMouseListener(ThreeDlistener);
addMouseMotionListener(ThreeDlistener);
}
public void paintBorderInset()
{
// … }
public void paintBorderRaised()
{
// … }
}
RMIT University © 2019 School of Science 16
Separate Listener (alternative)
class ThreeDButtonListener extends MouseAdapter
implements MouseMotionListener {
private ThreeDButton button;
public ThreeDButtonListener(ThreeDButton button) {
this.button=button;
}
public void mousePressed(MouseEvent event) {
button.paintBorderInset();
}
public void mouseClicked(MouseEvent event) {
button.paintBorderRaised();
}
public void mouseReleased(MouseEvent event) {
button.paintBorderRaised();
}
public void mouseDragged(MouseEvent event) {
if(button.contains(event.getX(), event.getY())) { if(button.getState() == ThreeDButton.BORDER_RAISED)
}
else {
} }
button.paintBorderInset();
if(button.getState() == ThreeDButton.BORDER_INSET) button.paintBorderRaised();
public void mouseMoved(MouseEvent event) { } }
RMIT University © 2019 School of Science
17
Separate Listener (alternative) • Advantages:
–maintains reference to source [does not need to call getSource() ]
–source/listener type checking done at compile time –source can be modified independently of listener
• Disadvantages:
–Less efficient since we must construct separate listener instances for each source even if functionality the same
RMIT University © 2019 School of Science 18
Combined Source/Listener
RMIT University © 2019 School of Science 19
Combined Source/Listener
• Advantages:
–no separate class is necessary –less lines of code
• Disadvantages:
Really advantageous?
–reduced cohesion (and harder to identify coupling)
–reduced extensibility (cannot modify source independently of listener)
–classes may become large and more difficult to maintain –less efficient (one listener instance per source)
Think carefully before using this approach!
RMIT University © 2019 School of Science 20
Named Inner Class
RMIT University © 2019 School of Science 21
Named Inner Class • Advantages:
–can automatically reference event source (because it is the enclosing class)
–does not need to call getSource() or maintain a reference (as in the two separate examples)
–maintains moderate encapsulation and cohesion
• Disadvantages:
–more difficult to share coding responsibilities (since they
are in the same code module)
–assumes a one to one mapping between source and listener instances (inefficient)
RMIT University © 2019 School of Science 22
Anonymous Inner Class
RMIT University © 2019 School of Science 23
Anonymous Inner Class • Advantages:
–provides a syntactic shortcut by combining the instantiation with the definition
–convenient for small handler methods
–can automatically reference event source (because it is the
enclosing class)
–does not need to call getSource() or maintain a reference (as in the two separate examples)
• Disadvantages:
–code clarity and cohesion may be reduced (since coupling is
implicit)
–more difficult to share coding responsibilities (since they are in the same code module)
–assumes a one to one mapping between source and listener instances
–anonymous classes can only be instantiated once (but can be assigned to a variable!)
RMIT University © 2019 School of Science 24