Multiple Window System and Bridge Pattern - Lecture Slides | CMSC 433, Study notes of Programming Languages

Material Type: Notes; Professor: Hicks; Class: PROG LANG TECH & PDGMS; Subject: Computer Science; University: University of Maryland; Term: Unknown 1989;

Typology: Study notes

Pre 2010

Uploaded on 02/13/2009

koofers-user-aj4
koofers-user-aj4 🇺🇸

10 documents

1 / 11

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
CMSC 433, Fall 2002
92
Multiple Window Systems
Want portability to different window systems
similar to multiple look
-
and
-
feel problem, but different
vendors will build widgets differently
Solution:
define abstract class Window, with basic window
functionality (e.g., draw,
iconify
, move, resize, etc.)
define concrete subclasses for specific types of
windows (e.g., dialog, application, icon, etc.)
define
WindowImp
hierarchy to handle window
implementation by a vendor
CMSC 433, Fall 2002
93
Implementation
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Multiple Window System and Bridge Pattern - Lecture Slides | CMSC 433 and more Study notes Programming Languages in PDF only on Docsity!

CMSC 433, Fall 2002 92

Multiple Window Systems

• Want portability to different window systems

  • similar to multiple look-and-feel problem, but different vendors will build widgets differently

• Solution:

  • define abstract class Window, with basic window functionality (e.g., draw, iconify, move, resize, etc.)
  • define concrete subclasses for specific types of windows (e.g., dialog, application, icon, etc.)
  • define WindowImp hierarchy to handle window implementation by a vendor

CMSC 433, Fall 2002 93

Implementation

CMSC 433, Fall 2002 94

Bridge Pattern

  • Name
    • Bridge or Handle or Body
  • Applicability
    • handles abstract concept with different implementations
    • implementation may be switched at run-time
    • implementation changes should not affect clients
    • hide a class’s interface from clients
  • Structure: use two hierarchies
    • logical one for clients,
    • physical one for different implementations

CMSC 433, Fall 2002 95

Structure of Bridge Pattern

CMSC 433, Fall 2002 98

Supporting User Commands (cont’d)

• An improved solution

  • create abstract “command” class
    • command must have reversible method
  • create action-performing glyph subclass
  • delegate action to command

• Key ideas

  • pass an object, not a function
  • pass context to the command function
  • store command history

CMSC 433, Fall 2002 99

Command Objects

CMSC 433, Fall 2002 100

Command Pattern

• Name

  • Command or Action or Transaction

• Applicability

  • parameterize objects by actions they perform
  • specify, queue, and execute requests at different times
  • support undo by storing context information
  • support change log for recovery purposes
  • support high-level operations
    • macros

CMSC 433, Fall 2002 101

Structure of Command Pattern

CMSC 433, Fall 2002 104

Spell-Checking and Hyphenation

• Must do textual analysis

  • multiple operations and implementations

• Must add new functions and operations easily

• Must efficiently handle scattered information and

varied implementations

  • different traversal strategies for stored information

• Should separate actions from traversal

CMSC 433, Fall 2002 105

Iterator Pattern

• Name

  • Iterator or Cursor

• Applicability

  • access aggregate objects without exposing internals
  • support multiple traversal strategies
  • uniform interface for traversing different objects

CMSC 433, Fall 2002 106

Iterator Pattern

  • Key ideas
    • separate aggregate structures from traversal protocols
    • support addition of traversal functionality
    • small interfaces for aggregate classes,
    • multiple simultaneous traversals
  • Pattern structure
    • abstract Iterator class defines traversal protocol
    • concrete Iterator subclasses for each aggregate class
    • aggregate instance creates instances of Iterator objects
    • aggregate instance keeps reference to Iterator object

CMSC 433, Fall 2002 107

Structure of Iterator Pattern

CMSC 433, Fall 2002 110

Iterator Pattern (cont’d)

• Implementation issues

• Who controls iteration?

  • external vs. internal iterators
    • external:
      • client controls the iteration via “next” operation
      • very flexible
      • some operations are simplified - logical equality and set operations are difficult otherwise
    • internal:
      • Iterator applies operations to aggregate elements
      • easy to use
      • can be difficult to implement in some languages

CMSC 433, Fall 2002 111

Iterator Pattern (cont’d)

• Who defines the traversal algorithm?

  • Iterator itself
    • may violate encapsulation
  • aggregate (in a “cursor”)
    • Iterator keeps only state of iteration

• How robust is the Iterator?

  • are updates or deletions handled?
  • don’t want to copy aggregates
  • register Iterators with aggregate and clean-up as needed
  • synchronization of multiple Iterators is difficult

This document was created with Win2PDF available at http://www.daneprairie.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only.