For graphic user interface (GUI)
Application, Multimedia System, etc
One system, different view
The View Handler design patterns help to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates dependencies between views and organizes their update
Multi-document editors allow several documents to be worked on simultaneously
Each document is displayed in its own window
Users can clone window and work with serveral independent views of the same document
Changes in one window may affect other windows as well
Need an efficient update mechanism for propagating changes between windows
A software system that provides multiple views of application-specific data, or that supports working with multiple documents
Need to support multiple views often need additional functionality for managing them
Views need to be coordinated
Need update propagated
Forces
- Managing multiple views must be easy for users and/or client components
- Individual views implementation should not be depended on others
- View implementation can be added during the lifetime of the system
Divide and Conquire
Separate the management of views from the code required to present or control specific views
A view handler component manages all views that the software system provides
It offers services opening, coordinating and closing
For example, tile all views to arrange them in an orderly pattern
Specific views, together with functionality for their presentation and control, are encapsulated within separate view component - one for each kind of view
Suppliers provide views with the data they needed
(Compared with Model-View-Controller, only remove responsibility of managing the entirely of views)
View handler is the central role, it opens new views
Client specify the view they want
(open-then-display, open-then-iconize)
It handles closing view as well
Main service is to offer view management services
For example, bring a specific view into several parts, to refresh all views, to clone views
Coordination of views
Serial update is coordinated if necessary (most global information should be updated first)
Class
Responsibility
Collaborators
|
Abstract view component defines an interface that is common to all views
View handler uses this interface for creating, coordinating and closing views
The backend will use the same interface to execute user events, e.g. resizing the window
Class
Responsibility
Collaborators
|
Specific view components are derived from the abstract view and implement its interface
Implement its own display function
Data are from suppliers
The display function is called when opening or updating a view
Class
Responsibility
Collaborators
|
Supplier components provide the data that is displayed by view components
They notify dependent components about change to their internal state
Class
Responsibility
Collaborators
|
ViewHandler ---- creates, closes, and coordinates -------------- AbstractView
| |
notifies inherits
| | |
| SpecificViewA SpecificViewB
| | |
Supplier ---------------------------------------------------------------------------- retrieves data --------
Scenario I: shows how the view handler creates a new view
Scenario II: Organizes the tiling of views
Identify the views
Specify a common interface for all views (should at least include functions to open, close, display, update, and manipulate a view)
Implement the views (add whatever patterns, or ticks ... double buffer, etc)
Define the view handler (hold control information about views, logging about animated simulation, serial update, remote access, etc)
View Handler with Command objects - use command objects to keep the view handler independent of specific view interfaces
View Handler with remote access (Proxy)
Macintosh Window Manager
Microsoft Word
Some variation of emac editor
Advantages
Uniform handling of views
Extensibility and changeability of views
Application-specific view coordination
Disadvantages
Restricted applicability - only if different views are needed
Efficiency