Download Design Patterns: State and Command Patterns in Object-Oriented Programming - Prof. Adam A. and more Study notes Programming Languages in PDF only on Docsity!
94
CMSC 433 – Programming Language
Technologies and Paradigms
Spring 2008
Design Patterns
February 26, 2008
State Pattern
• Problem
- An object is always in one of several known states
- The state an object is in determines the behavior of several methods
• Solution
- Could use if/case statements in each method
- Better solution: use dynamic dispatch
96
State Pattern Approach
• Encode different states as objects with same
superclass
• To change state, change the state object
• Methods delegate to state object
Example – Finite State Machine
class FSM { State state; public FSM(State s) { state = s; } public void move(char c) { state = state.move(c); } public boolean accept() { return state.accept();} } public interface State { State move(char c); boolean accept(); }
100
Instance of State Pattern
State Pattern Notes
• Can use singletons for instances of each state class
- State objects don’t encapsulate (mutable) state, so can be shared
• Easy to add new states
- New states can extend the base class, or
- New states can extend other states
- Override only selected functions
102
Lexi: Simple GUI-Based Editor
• Lexi is a WYSIWYG editor
- Supports documents with textual and graphical objects
- Scroll bars to select portions of the document
- Be easy to port to another platform
- Support multiple look-and-feel interfaces
• Highlights several OO design issues
• Case study of design patterns in the design of Lexi
Lexi User Interface
106
Structure of a Lexi Document
• Use recursive composition for defining and
handling complex objects
- Abstract class Glyph for all displayed objects
- Glyph responsibilities:
- Know how to draw itself
- Knows what space it occupies
- Knows its children and parent
- Glyph instances can recursively compose other Glyph instances
Recursive Composition
G g G g … User Display Objects column row row column row row
108
Glyph Class Diagram
The Composite Pattern
• Motivation:
- Support recursive composition in such a way that a client need not know the difference between a single and a composite object (as with Glyphs)
• Applicability:
- When dealing with hierarchically-organized objects (e.g., columns containing rows containing words …)
112
Formatting Lexi Documents: Strategy
• We know that documents are represented as
Glyphs, but not how documents are constructed.
• Formatting:
- Document structure will be determined based on rules for justification, margins, line breaking, etc.
- Many good algorithms exist;
- different tradeoffs between quality and speed
• Design decision: implement different algorithms,
decide at run-time which algorithm to use
- define root class that supports many algorithms
- each algorithm implemented in a subclass
Strategy Pattern
• Name
• Applicability
- Many related classes differ only in their behavior
- Many different variants of an algorithm
- Need to encapsulate algorithmic information
114
Strategy Pattern: Structure
Strategy Pattern: Consequences
• Clear separation of algorithm definition and use
- Glyphs and formatting algorithms are independent
- Alternative (many subclasses) is unappealing
- Proliferation of classes
- Algorithms cannot be changed dynamically
• Elimination of conditional statements
- Like State, Template, …
- Typical in OO programming
118
Class Diagram
Object Structure after Formatting
120
CMSC 433 – Programming Language
Technologies and Paradigms
Spring 2008
Design Patterns
February 28, 2008
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
124
Abstract Syntax Trees
public interface Node { } public class Number extends Node { public int n; } public class Plus extends Node{ public Node left; public Node right; }
Traversing Abstract Syntax Trees
public interface Node { public int sum(); } public class Number extends Node { public int n; public int sum() { return n; } } public class Plus { public Node left; public Node right; public int sum() { return left.sum() + right.sum(); } }
126
Naïve approach (not a visitor)
One method for each analysis
Use a Visitor
• Alternatively, can define a separate visitor class
- A visitor encapsulates the operations to be performed on an entire structure, e.g., all elements of a parse tree
• Allows operations to be separate from structure
- But doesn’t necessarily require putting all of the structure traversal code into each visitor/operation
130
Sample visited objects
Vistor Interaction
aNodeStructure aAssignmentNode aVariableRefNode aTypeCheckingVisitor Accept (aTypeChecking Visitor) VisitAssignment(aAssignmentNode) VisitVariableRef (aVariableRefNode) Accept (aTypeCheckingVisitor) someOperation() someOperation()
132
Visitor pattern
• Name
- Visitor or double dispatching
• Applicability
- Related objects must support different operations and actual op depends on both the class and the op type
- Distinct and unrelated operations pollute class defs
- Key : object structure rarely changes, but ops changed often
Visitor Pattern Structure
• Define two class hierarchies
- One for object structure
- AST in compiler, Glyphs in Lexi
- One for each operation family, called visitors
- One for typechecking, code generation, pretty printing in compiler
- One for spellchecking or hyphenation in Lexi
