GUI Tradeoffs

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

2. 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.

3. 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.

4. 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.)

5. 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.

6. 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

7. 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).

8. 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.

9. 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 Controller View

10. 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

11. Writing a Simple Swing Program • Go to http://www.patterndepot.com/put/8/JavaPatterns.htmand download the e-book and sample code available there. • 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.

12. 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.

13. 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.

14. 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.

15. ModelModelViewController • Randy Stafford points out at that there are usually two models involved http://c2.com/cgi/wiki?ModelModelViewController : • 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

16. 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.

17. 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 A link to this article and code implementing the Visual Proxy is available at http://www.holub.com/aiharticles.html • 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.

18. 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, whose job is to assemble the screen seen by the user, requests the visual proxies from the abstraction layer.

19. 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 is a tight coupling between an abstraction-layer 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 abstraction-layer object that creates them.

20. 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.

21. 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.

22. 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 abstraction-layer object that created it, as if a single object was actually in two places at once.

23. 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.

24. 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.

25. 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).

26. 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.

27. 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.

28. 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.

29. My Assessment • My experience is that you should do the simplest thing that works. You 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.’ (YAGNI). • 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.