Inside Smalltalk MVC: Patterns for GUI Programming

Transcription

1 Inside Smalltalk MVC: Patterns for GUI Programming Chien-Tsun Chen Department of Computer Science and Information Engineering National Taipei University of Technology, Taipei 106, Taiwan Dec

2 This talk introduces Smalltalk MVC and presents patterns for programming GUI applications MVC in Smalltalk: Something old, something new Four patterns for GUI programming Understanding the issues of pluggability and adaptors help us better applying MVC

3 References [KP88] G. E. Krasner and S. T. Pope, A Cookbook for Using the Model- View-Controller User Interface Paradigm in Smalltalk-80, JOOP, [Woolf94] B. Woolf, Understanding and Using ValueModels, [Lwsie95] S. Lewis, The Art and Science of Smalltalk, Prentice Hall, [VW95] VisualWorks Cookbook, Rev 2.0, ParcPlace-Digitalk, [GoF95] E. Gamma et. al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, [Ducasse00] S. Ducasse, Object-Oriented Design with Smalltalk a Pure Object Language and its Environment, [Fowlwe04] Martin Fowler, Organizing Presentation Logic, 2004,

4 MVC in Smalltalk

5 The basic concepts of MVC is separating the application logic from the user interface An application can have several user interfaces

6 The views and controllers work together to control the user interface to the models Input events are send to Controllers

7 Why Smalltalk separates views from controllers? To combine views and controllers in different ways to get different look & feel To allows views and controllers to inherit from different classes

8 The relationships between model, view and controller Controller does not dependent on Model

9 Another way to see the relationships between model, view and controller model access

10 MVC in action, phase 1: The window is opened and ButtonView send the message value to the ButtonModel 2 1

11 MVC in action, phase 2: The user clicks the mouse on the area of the screen and causes the reactions value: model value not

12 Remember the following import points of classic MVC architecture of Smalltalk [Lwsie95] 1. Neither the view nor the controller hold onto the model s state. 2. The controller doesn t know anything about the visual layout of the widget. When it needs that information, it asks the view. 3. When the controller changes the state of the model, it doesn t directly tell the view. 4. The model doesn t know about the view. When its state is changed by the controller, it s only because of the dependency mechanism that the view gets to know about the change. 5. When the model tells the view that it s changed, it doesn t tell the view the new state-it only tells it what aspect has changed.

13 What do you mean by MVC? View state Session state Record state Presentation Domain Data Source Model W. Model App. Model (P. Model) Domain Model Database View Widget Window Messaging System Transaction Management Controller Controller Presenter Other Packages Application So, what is the problem? External Systems

14 Data is copied between layers and applications have to coordinate and synchronize the data between layers Presentation Layer (screen state) Domain Layer (session state) Database External Systems (record state)

15 To use MVC well, we must realize the micro and macro perspectives of MVC View state Session state Record state Presentation Domain Data Source Model W. Model App. Model (P. Model) Domain Model Database View Widget Window Messaging System Transaction Management Controller Controller Presenter Other Packages call notify sync Application Three flows: call, notification, and (inter layer) synchronization External Systems

16 Smalltalk MVC (micro MVC) View state Session state Record state Presentation Domain Data Source Model W. Model M 3,u App. Model (P. Model) Domain Model Database View Controller V C Widget 2,w 4,r 1,r Controller Window Presenter Messaging System Transaction Management Other Packages 0,i Application External Systems

17 Smalltalk MVC (micro MVC) using ValueModel View state Session state Record state Model M1 VM 5,u Presentation 3,w App. Model (P. Model) Domain Domain Model 4,u M2 Data Source Database View Controller V C Widget 2,w 6,r 1,r Controller Window Presenter Messaging System Transaction Management Other Packages 0,i Application External Systems

18 Application Model (Presenter Model) in Smalltalk View state Session state Record state Presentation Domain Data Source Model View Controller 0,i W. Model V 7,r Widget 1,r 2,w Controller C 6,u M1 AM 5,r 3,w Window Presenter 4,u M2 Domain Model 3,w Database Messaging System Transaction Management Other Packages Application External Systems

19 Application Model (Presenter Model) in C# using data binding View state Session state Record state Model View Controller M1 W. Model 6,r Widget Controller Presentation 5,u V 1,d AM 4,r C M2 2,w Window Presenter Domain 3,u M3 Domain Model Data Source Database Messaging System Transaction Management Other Packages 0,i Application External Systems

20 Application Model (Presenter Model) in Java View state Session state Record state Model View Controller M1 W. Model Widget 1,r 11,r Controller Presentation 10,u 2,w 3,d V C M2 AM 9,w 8,r 7,u 6,r 4,w Window Presenter Domain 5,u M3 Domain Model Data Source Database Messaging System Transaction Management Other Packages 0,i 6,r Application External Systems

21 MVP (a): Macro MVC View state Session state Record state Model View Controller 0,i M1 W. Model 8,r 7,u Presentation Widget Controller 1,d V App. Model (P. Model) 6,w Window 2,r 5,r 3,w Presenter C Domain Domain Model 4,u M2 Data Source Database Messaging System Transaction Management Other Packages Application External Systems

22 MVP (b): Dumb View, Presenter connects View with Domain Model View state Session state Record state Model View Controller 0,i M1 W. Model 9,r 8,u Presentation Widget Controller 1,d V App. Model (P. Model) 7,w Window 2,r 6,w 5,r Presenter C 3,w Domain Domain Model 4,u M2 Data Source Database Messaging System Transaction Management Other Packages Application External Systems

23 MVP (c): Presenter as a ValueModel View state Session state Record state Model View Controller 0,i M1 W. Model 10,r 9,u Widget Controller Presentation 1,d V App. Model (P. Model) 8,w 2,r Window 5,u 6,r 7,r Presenter C M2 3,w Domain Domain Model 4,u M3 Data Source Database Messaging System Transaction Management Other Packages Application External Systems

24 Patterns for Organizing GUI Applications

25 We start from the widget level MVC (Micro MVC) V C V C V C V C V C M M or How to test a widget? (Consider the MVP pattern) M A widget Two widgets share the same model

26 Autonomous View: Put all presentation state and behavior for a window in a single class View has both state and behavior view state Autonomous View is difficult to test But it is easy to implement in small applications screen sync. (view state to record state) record state Database Database

27 A better Autonomous View: uses domain objects View has both state and behavior view state Autonomous View is difficult to test But it is easy to implement in small applications screen sync. (view state to session state) session state Domain Model (Data Source) record state Database Database

28 Presentation Model (Application Model) Type 1: the view synchronizes its state with PM frequently View has state but no behavior PM (AM) can be tested without UI, and supports multiple views view state field or key sync. Application Model (state & behavior) Application Model (state & behavior) session state screen sync. (view state to session state) Domain Model record state

29 Presentation Model (Application Model) Type 2: the view stores all its state in the Presentation Model View has no state and no behavior PM (AM) can be tested without UI, and supports multiple views view state auto sync. (if Aspect Adaptor or Pluggable Adaptor is available) Application Model (state & behavior) but usually Application Model (state & behavior) session state screen sync. (view state to session state) Domain Model record state

30 MVP: separates the behavior of a presentation from the view while allowing the view to receive user events (Macro MVC) Dumb view (has state but not behavior) hooks (by stubbing view, Presenter can be tested) V view state Presenter (no state, only behavior) doesn t have to sync. date (All events are delegated to Presenter) Presenter (no state, only behavior) C session state screen sync. (view state to session state) Domain Model M record state

31 Review the four patterns: MVC, AV, PM, and MVP V C M Micro MVC (Widget) Autonomous View Presenter Model (Application Model) MVP (Macro MVC)

32 Pluggability and Adaptors

33 The problem comes from the original idea of MVC: separating application logic (model) from UI View/ Controller Model a = 50% b = 30% c = 20% From the model s perspective, an application can have several user interface (reuse model)

34 If we look at MVC from the View s perspective View/ Controller Model C :Object From the view s perspective, a view may use different kind of models (reuse view) :String

35 Connecting a widget to a model by (Pluggable) Adapter pattern (to find a narrow interface for Adaptee) Database AST (Target) File System XML TreeView (Client) Model (Adaptee)

36 Adaptors connect UI objects (widgets) which speak only value/value: to model objects with their own protocol Specific and simple interface (protocol) UI Object (Client) value value: Adaptor (Target, Adapter) model protocol Model Object (Adaptee)

37 ValueModel solves the problem of change notification, sharing, and adaptation (abstract class) A portion of the class hierarchy showing subclasses of ValueModel

38 ValueHolder title title title: value (String) atexteditorview V & C value value: avalueholder DA avaluehlder onchangesend: refresh to: Album domain model A ValueHolder is an object that encapsulates a value and allows it to behave like a model, that is, notifies the dependents of the model automatically when it is changed. It is most useful for widgets that accept temporary pieces of information that the interface must hold onto until they can be further processed.

39 AspectAdaptor atexteditorview value value: subject anaspectadaptor title title: V & C aspect DA domain model Widgets are commonly used for presenting data that is held by some object in the application, such as a domain model. In such cases, the appropriate value model is an AspectAdaptor, which is conceptually a pointer to the remote data. AspectAdaptor also support unusual accessors.

40 PluggableAdaptor (custom adaptor) atexteditorview David Lee Mr. David Lee V & C value value: anpluggableadaptor getblock putblock updateblock DA domain model A PluggableAdaptor performs a block of actions each time its value is accessed or changed. It takes three blocks, which enable it to perform custom actions at three junctures in the flow of communication between the widget and the domain model.

41 VisualWorks extends MVC by splitting the model into application model and data model (domain model) browsers, dialogs, editors, etc. collection objects, strings, numbers, booleans, files, etc. Dual role of model objects: They act as a store for the application s data, and they act upon that data in application specific ways

42 An Application Model is a model that is responsible for creating and managing a runtime UI, usually consisting of a single window. It manages only application information, leaving the domain information to its aspect models

43 The fine-grained structure of an Application sync sync

44 Review of the Presentation Model Pattern (1/2) Represent the state and behavior of the presentation independently of the GUI controls used in the interface (domain model)

45 Review of the Presentation Model Pattern(2/2) GUIs consist of widgets that contain the state of the GUI screen. Leaving the state of the GUI in widgets makes it harder to get at this state, since that involves manipulating widget APIs, and also encourages putting presentation behavior in the view class. Presentation Model pulls the state and behavior of the view out into a model class that is part of the presentation. The Presentation Model coordinates with the domain layer and provides an interface to the view that minimizes decision making in the view. The view either stores all its state in the Presentation Model or synchronizes its state with Presentation Model frequently.

46 Conclusion: Remember the four pictures Question?

47 Combine views & controllers in different ways to get different Look & Feel Using different views to get a different look Using different controllers to get a different feel

48 Smalltalk dependency mechanism : I want to know whenever your values have been changed obja objb Static structure objb is dependent on obja changed message obja dependents update message objb Dynamic behavior

49 The changed message and the update message of the dependency mechanism size: anumber size := anumber. self changed: #size. obja changed: anaspect with: aparm (two parameters) obja changed: anaspect (one parameter) obja changed. (no parameters) dependent update: anaspect with: aparm from: anobj. (three parameters) dependent update: anaspect with: aparm. (two parameters) dependent update: anaspect. (one parameter) update: anaspect anaspect = #color iftrue: [self redraw]. anaspect = #size iftrue: [self redraw].

50 Comparing the Observer sequence diagram with the MVC pattern (1/3) Model View 1 View 2

51 Comparing the Observer sequence diagram with the MVC pattern (2/3) Model Controller View

52 Comparing the Observer sequence diagram with the MVC pattern (3/3) Model View 1 View 2 SetState()

53 The MVC uses the one parameter version of changed value: model value not value: aboolean value := aboolean. self changed: #value. obja changed: anaspect with: aparm (two parameters) obja changed: anaspect (one parameter) obja changed. (no parameters)

54 The MVC uses the one parameter version of update dependent update: anaspect with: aparm from: anobj. (three parameters) dependent update: anaspect with: aparm. (two parameters) dependent update: anaspect. (one parameter) update: anaspect anaspect = #value iftrue: [self redraw]. anaspect = #size iftrue: [self redraw].

55 Instance variables of an MVC Triad for a running CounterView M V C

56 Let s look at a Swing JButton example: each widget is a UI component AbstractButton setmodel() JComponent setui() AbstractButton Swing UI Component

57 AbstractButton, ButtonModel and ComponentUI ComponentUI ButtonModel AbstractButton

58 There are two ways of looking at MVC: macro and micro Presenter (Controller) MVC in the small (widget level) View MVC in the large (application level) Model

59 The fine-grained structure of an Application sync sync

60 An example of MPV pattern (class diagram) M P V Design for testability M P V copy & modify

61 Why split the model into two pieces? Splitting the model in this way removes application specific processing from the data model, making it much more reusable. It also provides something, of a justification for putting some user-interface functionality in the application model. After all, in some cases an application is nothing more than a particular set of operations with a particular userinterface. Consequently, it doesn t matter too much if the application model knows some things about the user-interface. In this case the application is the interface [1, p. 100].

62 Why split the model into two pieces?

63 ValueModel looks like a point to point in C View 1 Model 1 View 1 Model 1 View 2 An object is shared directly View 2 (replace) The object is longer shared Model 2 View 1 Value Model View 1 Value Model View 2 An object is shared by ValueModel Model 1 View 2 (replace) The object is still shared Model 2