GUI Tradeoffs

CSE301/COM379 University of Sunderland Harry R. Erwin, PhD

Review: Pattern Languages

• Alexander (1977) invented the idea of a pattern language as a practical tool for describing architectural expertise in some domain. • The elements of a pattern language are patterns. Each pattern describes a problem that occurs over and over again, and then describes the core of the solution to that problem in such a way that it can be reused many times, never once doing it the same way.

• A pattern isn’t considered proven until it has been used at least three times in real applications.

Review: Design Patterns

• The four essential elements (Gamma, et al) of a design pattern are: – A descriptive name – A problem description that shows when to apply the pattern and to what contexts. The description explains how it helps to complete larger patterns.

– A solution that abstractly describes the constituent elements, their relationships, responsibilities, and collaborations. – The results and trade-offs that should be taken into account when applying the pattern.

Resources

• Gamma, Helm, Johnson, and Vlissides, 1995,

Design Patterns,

Addison-Wesley.

• Cooper, 1998,

The Design Patterns Java Companion,

Addison-Wesley, available free from http://www.patterndepot.com/put/8/JavaPatterns.htm

, the sample code in the book is available as http://www.patterndepot.com/put/8/JavaPatterns.ZIP

.

• The Portland Pattern Repository: http://c2.com/ppr/ • Alexander, 1977,

A Pattern Language: Towns/Buildings/ Construction,

Oxford University Press. (For historical interest.)

Graphical User Interfaces

• An architectural problem we will examine is the graphical user interface (GUI).

• We will explore several patterns: – MVC http://c2.com/cgi/wiki?ModelViewController

– Modified MVC – MMVC – Visual Proxy http://c2.com/cgi/wiki?VisualProxy

– Modified Visual Proxy • This discussion is

advanced

, and you should consult the various documents you see referenced.

Problem Description

• • Not all people can or prefer to operate a computer in the same way.

Therefore:

Separate the controls of the computer from the views it presents so that appropriate controls can be selected by the user. • A handicapped individual would be an example of a user needing a different kind of control. – attributed to Adele Goldberg at http://c2.com/cgi/wiki?ModelViewController

A Solution—the Model/View/ Controller (MVC) Pattern

• The MVC paradigm is a way of breaking an application, or even just a piece of an application's interface, into three parts: the model, the view, and the controller. (Dean Helman, based on material at http://ootips.org/mvc pattern.html

) • MVC was originally developed to map the traditional input, processing, output roles into the GUI realm: Input --> Processing --> Output Controller --> Model --> View • javax.swing supports the MVC paradigm (and others).

MVC Implementation • The modeling of the external world, visual feedback, and user input are handled separately by

model

,

viewport

, and

controller

subsystems. • The

model

manages one or more data elements, responding to queries about and to instructions to change their state. • The

viewport

manages an area of the display and is responsible for presenting data to the user. In Java, you use Components, Containers, and LayoutManagers to do this. • The

controller

interprets mouse and keyboard inputs from the user mapping them into commands that are sent to the model and viewport. In Java, this is done using

events

and

event listeners

.

The Structure of the MVC

The model, viewport and controller are in constant contact and must reference each other. The need for these links is a major criticism of MVC, since they violate modularity. This picture illustrates the basic Model-View-Controller relationships: Model View Controller

MVC Design Details

• A swing GUI consists of – Components – Containers – A LayoutManager – EventListeners – A model that the components provide views of and that the eventlisteners manipulate.

• A swing JComponent automatically provides – Keystroke handling – A border – Tooltips – Automatic scrolling if required

Writing a Simple Swing Program

• Go to download the e-book and sample code available there.

http://www.patterndepot.com/put/8/JavaPatterns.htm

and • Unzip the files and put the folder in a convenient location. The code is designed to work with Java 1.1, so you probably want to go through the .java files and replace “com.sun.java” with “javax”. Work the examples in Part 2 of the book using the code provided.

Discussion

• The “simple two button program” on pages 56-58 of

Java Patterns

is a version of the MVC pattern.

– Model: the color choice – View: the JxFrame and its contents – Controller: Also the JxFrame as it provides an ActionListener.

• If the View and Controller were implemented separately, this would be the classical MVC pattern. • The hassle involved in linking a button event to a button color change shows why View and Controller are often combined.

Criticisms of the MVC

• MVC is a complex, heavy-weight pattern that is hard to set up and adapt to specific problems. • It involves multiple threads and objects, and hence can be slow.

• There is strong coupling between most components. This doesn’t scale well, since the number of interfaces increases more rapidly than the number of objects.

Modified MVC Pattern

• Often two of the elements are combined to overcome these problems: – Model+View – Model+Controller – View+Controller • For example, most Java GUIs combine the View and Controller subsystems. This is done by having the View objects handle almost all events.

• This makes the links between elements of the pattern conveniently

implicit

rather than

explicit

. The number of threads is reduced and many interfaces are hidden.

• Coupling and complexity remain high. That’s why we spend a lot of time on this topic.

ModelModelViewController

• Randy Stafford points out at that there are usually

two

http://c2.com/cgi/wiki?ModelModelViewController

: models involved – A domain model—the object model of the problem domain.

– An application model—which encapsulates the adaption of a GUI to a specific domain. (In javax.swing, Panels and Frames would form the application model.) • To build this involves explicitly linking the four subsystems of the pattern together. This violates modularity (Lectures 1-2) even more than the standard MVC pattern.

• If this is valid, it means the MVC paradigm, as it usually is understood, lacks flexibility. The Model

can’t

be isolated from the GUI design. 8( • For a discussion see: http://www.object-arts.com/EducationCentre/Overviews/MVC.htm

Discussion of MVC

• I’ve been teaching a variant on the MVC, with the V and C components closely coupled, the business logic implemented in a first (intermediate) model component, and the business entities implemented in a second model component.

• The first model component, with the business model, usually supports the GUI design fairly explicitly.

• Obviously from this lecture, there are other options.

An Alternative Solution—the Visual Proxy ‘Pattern’

• This material is drawn from the discussion in Holub, http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox_p.html

link to this article and code implementing the Visual Proxy is available at http://www.holub.com/aiharticles.html

A • This approach abandons the MVC pattern, replacing it with a three-layer pattern that reflects the distinction between the two types of model. This specializes the Presentation/ Abstraction/Control (PAC) architecture in

Pattern Oriented Software Architecture: A System of Patterns,

by Buschmann, et al.

• The

abstraction layer

in the PAC architecture is an application model of objects that directly model abstract concepts in the domain model. The classes for those objects reflect user needs analysis, and should not have a specific presentation mandated.

PAC Layers

• The classes responsible for drawing on the screen comprise the

presentation layer

and are called proxy classes.

• These proxy classes render one or more attributes of the classes making up the the

abstraction layer (

and that form the Application Model).

• The

control layer

from the , whose job is to assemble the screen seen by the user, requests the visual proxies

abstraction layer

.

Coupling via the

Abstraction Layer

• The proxies are abstract from the perspective of the control object so there is no coupling between the control layer and the other layers. • • There

layer is

a tight coupling between an

abstraction-

class and its proxy classes (usually as Observer/Observable), but the proxies are not coupled to each other.

Abstraction-layer

objects may and usually do communicate with each other, but proxies communicate only with the object that creates them.

abstraction-layer

Implementing the Visual Proxy

• The Swing “separable-model” architecture provides a good way for a

presentation layer

to communicate with an

abstraction layer

. • The Swing

UI Delegate

(page 23 of

Java Foundation Classes in a Nutshell

)—without a model object installed—can serve as a visual proxy.

• A Swing model object (such as a ListModel or Document) stores the state of some attribute inside an

abstraction-layer

object—it's actually a field of the

abstraction-layer

class.

Advanced Implementation Details

• The UI Delegate (a JList or JTextField) is created when the presentation layer asks the

abstraction layer

for a visual proxy. The UI Delegate is then hooked up to the model object, usually in an Observer/Observable relationship. • Proxy changes are then reflected directly in the abstraction side object. To the abstraction-layer object, the state of the model changes magically as the user interacts with the associated UI Delegate. • You must synchronize access (Lecture 20) when the model field is accessed while a form is displayed. User modifications happen in the Swing event-loop thread, not in the thread that's examining the state of the object.

Using AWT in the Visual Proxy

• An alternative approach is to use an AWT object as the visual proxy and then register some inner class (Lecture 9) object of the

abstraction-layer

object as an event listener. • Events flow directly from the proxy to the

abstraction layer

with no MVC “controller”. • The visual proxy is part of the actually in two places at once.

abstraction-layer

object that created it, as if a single object was

Visual Proxy Tradeoffs 1

• Proxies are best implemented as separate classes. • The abstraction-layer object should provide a proxy that can do the rendering. • The render-yourself strategy is not workable unless the object is actually simple in nature (i.e., a String). The distinction between domain model and presentation is meaningful.

Visual Proxy Tradeoffs 2

• You don't want to rewrite a class to change the appearance of an object on the screen. • Because the visual proxy is a separate class, objects of that class can be provided by an Abstract Factory (Lecture 22). • Proxies can often be implemented generically— uncoupled to the abstraction layer. A Swing JTextField, e.g., can be used as a proxy for an attribute stored in a Document object.

Visual Proxy Tradeoffs 3

• What is needed is an interface that can be used only between the proxy and the object that it represents—which are tightly coupled. You might consider an inner class (Lecture 10) implementation of a private proxy class.

• If you use this strategy, however, derived classes can no longer supply proxies, and you violate the Open-Closed Principle (Lecture 3).

Visual Proxy Criticisms

• The Visual Proxy “pattern” is completely

unproven

.

• There is no evidence that the Visual Proxy pattern scales any better than MVC.

• The objects of the model should not be responsible for adapting themselves to the user interface.

• Many GUIs need to present multiple views of the same model object.

• My experience is that proxies are extra baggage.

Modified Visual Proxy Concept

• Instead of having model objects provide proxies, use a Factory or AbstractFactory pattern (Lecture 22) to create proxies (Adaptor pattern, Lecture 24). • The model objects provide generalized iterators (Lecture 24) and state change events that the proxies listen to, and in turn listen for parameter change events from the proxies.

• The proxies define the presentation of the object data and provide display controls to the user.

• Note this concept is also

unproven

.

Summary

• The MVC allows you to separate the implementation of the interface from the model. This is good if you have to adapt to local or individual requirements, but is slow and hard to implement and violates modularity.

• You can simplify the MVC. View+Controller is usual, with controller objects implemented as inner classes of the corresponding views.

• The Visual Proxy separates the application model from the domain model, but is harder to adapt to special user needs. Implementation is even more complex than for the MVC and probably inappropriate for simple projects.

• You can also modify the Visual Proxy to use the Factory pattern to create the proxies. This is

unproven

.

My Assessment

• My experience is that you should do the simplest thing that works. You (YAGNI).

should

use a three-layer architecture, but you shouldn’t start by deciding to build an MVC or Visual Proxy pattern—‘you ain’t going need it.’ • Instead, build a presentation layer to display and handle what you need to handle, use focus-lost events to drive changes to the model, have the model adapt to those changes, and use the Observer/Observable pattern to then change the presentation layer.

• If you need proxies or controller/view elements, you can add them later, rather than earlier, as long as your basic architecture starts out good.