1 Expression Trees

A Case Study of Gang of Four (GoF) Patterns: Part 1
d.schmidt@vanderbilt.edu www.dre.vanderbilt.edu/~schmidt Professor of Computer Science Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee, USA
Douglas C. Schmidt
GoF Patterns Expression Tree Case Study
Douglas C. Schmidt
Topics Covered in this Part of the Module

Describe the object-oriented (OO) expression tree case study
Binary Nodes
Unary Node
Leaf Nodes
Douglas C. Schmidt
Case Study: Expression Tree Processing App

Goals Develop an OO expression tree processing app using patterns & frameworks
Design Problem Extensible expression tree structure Encapsulating variability & simplifying memory management Parsing expressions & creating expression tree Extensible expression tree operations Implementing STL iterator semantics Consolidating user operations Consolidating creation of variabilities for commands, iterators, etc. Ensuring correct protocol for commands Structuring application event flow Supporting multiple operation modes Centralizing access to global resources Eliminating loops via the STL std::for_each() algorithm Pattern(s) Composite Bridge Interpreter & Builder Iterator & Visitor Prototype Command Abstract Factory & Factory Method State Reactor Template Method & Strategy Singleton Adapter
3 ambiguity in algebraic expressions Expression trees are used to remove
Douglas C. Schmidt

Goals Develop an OO expression tree processing app using patterns & frameworks Compare/contrast nonobject-oriented & objectoriented approaches
Expression_Tree
Component_Node
Composite_ Unary_Node
Leaf_Node
1 Tree Node 0|1|2
Composite_Binary _Node
Composite_Negate _Node
Composite_ Add_Node Composite_ Multiply_Node
Composite_ Subtract_Node Composite_ Divide_Node
4 Despite decades of OO emphasis, algorithmic decomposition is still common
Douglas C. Schmidt

Goals Develop an OO expression tree processing app using patterns & frameworks Compare/contrast nonobject-oriented & objectoriented approaches Demonstrate Scope,
Binary Nodes
Commonality, & Variability (SCV) analysis in the context

of a concrete example
Unary Node Leaf Nodes
SCV is a systematic software reuse method
www.cs.iastate.edu/~cs309/references/CoplienHoffmanWeiss_CommonalityVariability.pdf 5
Douglas C. Schmidt

Goals Develop an OO expression tree processing app using patterns & frameworks Compare/contrast nonobject-oriented & objectoriented approaches Demonstrate Scope,
Expression_Tree expr_tree = ; Print_Visitor print_visitor; C++11 range-based for loop for (auto &iter : expr_tree) iter.accept(print_visitor);
Commonality, & Variability
(SCV) analysis in the context of a concrete example
Illustrate how patternoriented OO frameworks can be implemented in C++ & Java
ExpressionTree exprTree = ; ETVisitor printVisitor = new PrintVisitor(); Java for-each loop for (ComponentNode node : exprTree) node.accept(printVisitor);
Douglas C. Schmidt
Overview of Expression Tree Processing App

Expression trees consist of nodes containing operators & operands
Binary Nodes
7 See en.wikipedia.org/wiki/Binary_expression_tree for expression tree info
Douglas C. Schmidt

Expression trees consist of nodes containing operators & operands Operators are interior nodes in the tree i.e., binary & unary nodes
Unary Node Binary Nodes
Douglas C. Schmidt

Expression trees consist of nodes containing operators & operands Operators are interior nodes in the tree i.e., binary & unary nodes Operands are exterior nodes in the tree i.e., leaf nodes
Unary Node Leaf Nodes Binary Nodes
Douglas C. Schmidt

Expression trees consist of nodes containing operators & operands Operators have different precedence levels, different associativities, & different arities, e.g.:
Unary Operator Leaf Nodes Binary Operators
10
Douglas C. Schmidt

Expression trees consist of nodes containing operators & operands Operators have different precedence levels, different associativities, & different arities, e.g.: The multiplication operator has two arguments, whereas unary minus operator has only one
11
Douglas C. Schmidt

Expression trees consist of nodes containing operators & operands Operators have different precedence levels, different associativities, & different arities, e.g.: The multiplication operator has two arguments, whereas unary minus operator has only one Operator locations in the tree unambiguously designate precedence
12
Douglas C. Schmidt

Expression trees consist of nodes containing operators & operands Operators have different precedence levels, different associativities, & different arities Operands can be integers, doubles, variables, etc. We'll just handle integers in this example, though it can easily be extended
Unary Operator Integer Operands Binary Operators
13
Douglas C. Schmidt

Trees may be evaluated via different traversal orders, e.g., in-order iterator = -5*(3+4) pre-order iterator = *-5+34 post-order iterator = 5-34+* level-order iterator = *-+534
14 See en.wikipedia.org/wiki/Binary_expression_tree#Traversal for more info
Douglas C. Schmidt

Trees may be evaluated via different traversal orders, e.g., in-order iterator = -5*(3+4) pre-order iterator = *-5+34 post-order iterator = 5-34+* level-order iterator = *-+534 The evaluation step may perform various actions, e.g.: Print contents of expression tree Return the value" of the expression tree Perform semantic analysis & optimization Generate code etc.
15
1. S = [5] 2. S = [-5] 3. S = [-5, 3] 4. S = [-5, 3, 4] 5. S = [-5, 7] 6. S = [-35]
push(node.item()) push(-pop()) push(node.item()) push(node.item()) push(pop()+pop()) push(pop()*pop())
Douglas C. Schmidt
Summary
The expression tree processing app can be run in multiple modes, e.g.: Succinct mode % tree-traversal > 1+4*3/2 7 > (8/4) * 3 + 1 7 ^D Verbose mode % tree-traversal -v format [in-order] expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit > format in-order > expr 1+4*3/2 > print post-order 143*2/+ > eval post-order 7 > quit
16

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques
Start
Initialize Prompt User Read Expr Build Tree Process Tree No EOF? Yes End
18
Douglas C. Schmidt
How Not to Design an Expression Tree Application

Apply algorithmic decomposition Top-down design based on the
actions performed by the system
Start Initialize Prompt User
A
Read Expr Build Tree Process Tree
B
No EOF? Yes End
19
Douglas C. Schmidt

Start
A
Yes Verbose? No Verbose Prompt Succinct Prompt
Initialize Prompt User
Generally follows a divide &

conquer strategy based on the actions
A
Read Expr Build Tree Process Tree
i.e., general actions are

iteratively/recursively decomposed into more specific ones
B
Yes Print? No Print Tree Yes Eval Tree
B
No EOF? Yes End
Eval? No
20
Douglas C. Schmidt

typedef struct Tree_Node { ... } Tree_Node; Well explore this shortly void prompt_user(int verbose); char *read_expr(FILE *fp); Tree_Node *build_tree (const char *expr); void process_tree (Tree_Node *root, FILE *fp); void eval_tree (Tree_Node *root, FILE *fp); void print_tree (Tree_Node *root, FILE *fp); ... Well explore this shortly 21
Generally follows a divide &

conquer strategy based on the actions
i.e., general actions are

iteratively/recursively decomposed into more specific ones
Primary design components e.g., C functions
correspond to processing steps in execution sequence
Douglas C. Schmidt
Algorithmic Decomposition of Expression Tree

A typical algorithmic decomposition for implementing expression trees
Type tag typedef struct Tree_Node { enum { NUM, UNARY, BINARY } tag_; short use_; Reference count union { char op_[2]; Node value int num_; } o; #define num_ o.num_ #define op_ o.op_ union { struct Tree_Node *unary_; struct { struct Tree_Node *l_, *r_;} binary_; } c; #define unary_ c.unary_ Node child(ren) #define binary_ c.binary_ } Tree_Node; 22
would use a C struct/union to represent the main data structure
Douglas C. Schmidt

A typical algorithmic decomposition for implementing expression trees
would use a C struct/union to represent the main data structure
Memory Layout
tag_ use_ op_ num_
typedef struct Tree_Node { enum { NUM, UNARY, BINARY } tag_; short use_; union { char op_[2]; int num_; } o; #define num_ o.num_ #define op_ o.op_ union { struct Tree_Node *unary_; struct { struct Tree_Node *l_, *r_;} binary_; } c; #define unary_ c.unary_ #define binary_ c.binary_ } Tree_Node; 23
Class Relationships 1 Tree Node 0|1|2
unary_
binary_
Douglas C. Schmidt

A typical algorithmic decomposition uses a switch statement & a recursive
function to build & evaluate a tree, e.g.:
void print_tree(Tree_Node *root, FILE *fp) { switch(root->tag_) { Switch on type tag case NUM: fprintf(fp, "%d", root->num_); break; case UNARY: fprintf(fp, "(%s", root->op_[0]); print_tree(root->unary_, fp); fprintf(fp, ")"); break; case BINARY: fprintf(fp, "("); print_tree(root->binary_.l_, fp); fprintf(fp, "%s", root->op_[0]); print_tree(root->binary_.r_, fp); fprintf(fp, ")"); break; ... } 24
Douglas C. Schmidt

void print_tree(Tree_Node *root, FILE *fp) { switch(root->tag_) { case NUM: fprintf(fp, "%d", root->num_); break; case UNARY: fprintf(fp, "(%s", root->op_[0]); print_tree(root->unary_, fp); fprintf(fp, ")"); break; case BINARY: fprintf(fp, "("); print_tree(root->binary_.l_, fp); fprintf(fp, "%s", root->op_[0]); print_tree(root->binary_.r_, fp); fprintf(fp, ")"); break; ... } 25
Douglas C. Schmidt

void print_tree(Tree_Node *root, FILE *fp) { switch(root->tag_) { case NUM: fprintf(fp, "%d", root->num_); break; case UNARY: fprintf(fp, "(%s", root->op_[0]); print_tree(root->unary_, fp); Recursive call fprintf(fp, ")"); break; case BINARY: fprintf(fp, "("); print_tree(root->binary_.l_, fp); fprintf(fp, "%s", root->op_[0]); print_tree(root->binary_.r_, fp); fprintf(fp, ")"); break; ... } 26
Douglas C. Schmidt

void print_tree(Tree_Node *root, FILE *fp) { switch(root->tag_) { case NUM: fprintf(fp, "%d", root->num_); break; case UNARY: fprintf(fp, "(%s", root->op_[0]); print_tree(root->unary_, fp); fprintf(fp, ")"); break; case BINARY: fprintf(fp, "("); print_tree(root->binary_.l_, fp); Recursive call fprintf(fp, "%s", root->op_[0]); print_tree(root->binary_.r_, fp); Recursive call fprintf(fp, ")"); break; ... } 27
Douglas C. Schmidt
Summary
Limitations with algorithmic decomposition Little/no encapsulation
Implementation details available to clients
typedef struct Tree_Node { enum { NUM, UNARY, BINARY } tag_; short use_; union { char op_[2]; int num_; Small changes ripple } o; through entire program #define num_ o.num_ #define op_ o.op_ union { struct Tree_Node *unary_; struct { struct Tree_Node *l_, *r_;} binary_; Use of macros pollutes } c; global namespace #define unary_ c.unary_ #define binary_ c.binary_ } Tree_Node; 28
Douglas C. Schmidt
Summary
Limitations with algorithmic decomposition Incomplete modeling of application domain
typedef struct Tree_Node { enum { NUM, UNARY, BINARY } tag_; short use_; union { Tight coupling char op_[2]; between int num_; nodes/edges } o; in union #define num_ o.num_ #define op_ o.op_ union { struct Tree_Node *unary_; struct { struct Tree_Node *l_, *r_;} binary_; Wastes space by } c; making worst-case #define unary_ c.unary_ assumptions wrt #define binary_ c.binary_ structs & unions } Tree_Node; 29
tag_ use_ op_ num_
unary_
binary_
Douglas C. Schmidt
Summary
Limitations with algorithmic decomposition
Tree_Node data structure is passive & functions do all the real work
Complexity in (variable) algorithms rather than (stable) structure

void print_tree(Tree_Node *root, FILE *fp) { switch(root->tag_) { case NUM: fprintf(fp, "%d", root->num_); break; case UNARY: fprintf(fp, "(%s", root->op_[0]); Easy to make mistakes print_tree(root->unary_, fp); when switching on type tags fprintf(fp, ")"); break; case BINARY: fprintf(fp, "("); Tailoring the app for print_tree(root->binary_.l_, fp); specific requirements & fprintf(fp, "%s", root->op_[0]); specifications impedes print_tree(root->binary_.r_, fp); reuse & complicates fprintf(fp, ")"); break; software sustainment ... } 30 modeling, design, & implementation Overcoming limitations requires rethinking

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques Present an OO design for the expression tree processing app
Component_Node Expression_Tree
Leaf_Node
32
Douglas C. Schmidt
How to Design an Expression Tree Processing App

Apply an Object-Oriented (OO) design based on modeling classes & objects in the application domain
Binary Nodes
Unary Node
Leaf Nodes
33
Douglas C. Schmidt

Apply an Object-Oriented (OO) design based on modeling classes & objects in the application domain Employ hierarchical data abstraction where design components are based on stable class & object roles & relationships Rather than functions corresponding to actions
Post_Order_ET _Iterator_Impl In_Order_ET _Iterator_Impl ET_Iterator
ET_Iterator_Impl
Level_Order_ET _Iterator_Impl
Pre_Order_ET _|Iterator_Impl
34
Douglas C. Schmidt

Apply an Object-Oriented (OO) design based on modeling classes & objects in the application domain Employ hierarchical data abstraction where design components are based on stable class & object roles & relationships Associate actions with specific objects and/or classes of objects Emphasize high cohesion & low coupling
Event_Handler
ET_Event_Handler handle_input() prompt_user() get_input() make_command() execute_command()
Verbose_ET_ Event_Handler prompt_user() make_command()
Succinct_ET_ Event_Handler prompt_user() make_command()
35
Douglas C. Schmidt

Apply an Object-Oriented (OO) design based on modeling classes & objects in the application domain Employ hierarchical data abstraction where design components are based on stable class & object roles & relationships Associate actions with specific objects and/or classes of objects Group classes & objects in accordance to patterns & combine them to form
Reactor
Reactor
Event_Handler
Singleton
Options
ET_Command_Factory
ET_Event_Handler
ET_Context
<< create >>
Verbose_ET_ Event_Handler
Succinct_ET_ Event_Handler
ET_Command
Strategy & Template Method
frameworks
36
Douglas C. Schmidt
An OO Expression Tree Design Method

Start with object-oriented (OO) modeling of the expression tree application domain
37
Douglas C. Schmidt

Applicationdependent steps Binary Nodes
Model a tree as a collection of nodes
38
Douglas C. Schmidt

Applicationdependent steps
Component_Node
Model a tree as a collection of nodes Represent nodes as a hierarchy, capturing properties of each node e.g., arities
Leaf_Node
39
Douglas C. Schmidt

Applicationdependent steps
Composite
Expression_Tree Component_Node
Model a tree as a collection of nodes
Bridge
Leaf_Node
Represent nodes as a hierarchy, capturing properties of each node e.g., arities
Composite_ Add_Node
Composite_ Multiply_Node
Composite_ Subtract_Node
Composite_ Divide_Node
Applicationindependent steps
Conduct Scope, Commonality, & Variability analysis to determine stable interfaces & extension points Apply Gang of Four (GoF) patterns to guide efficient & extensible development of framework components Integrate pattern-oriented language/library features w/frameworks
en.wikipedia.org/wiki/Design_Patterns40 has info on Gang of Four (GoF) book
Douglas C. Schmidt
C++ Pattern-Oriented Language/Library Features

Over time, common patterns become institutionalized as programming language features
Expression_Tree expr_tree = ; Print_Visitor print_visitor; Visitor object (based on Visitor pattern)
41
Douglas C. Schmidt

Expression_Tree expr_tree = ; Print_Visitor print_visitor;
for (Expression_Tree::iterator iter = expr_tree.begin(); iter != expr_tree.end(); Traditional STL ++iter) iterator loop (*iter).accept(print_visitor);
42
Douglas C. Schmidt

Expression_Tree expr_tree = ; Print_Visitor print_visitor; for (Expression_Tree::iterator iter = expr_tree.begin(); iter != expr_tree.end(); ++iter) (*iter).accept(print_visitor);
std::for_each (expr_tree.begin(), expr_tree.end(), [&print_visitor] (const Expression_Tree &t) { t.accept(print_visitor);}); C++11 lambda expression
43
Douglas C. Schmidt

Expression_Tree expr_tree = ; Print_Visitor print_visitor; for (Expression_Tree::iterator iter = expr_tree.begin(); iter != expr_tree.end(); ++iter) (*iter).accept(print_visitor);
C++11 range-based for loop
std::for_each (expr_tree.begin(), expr_tree.end(), [&print_visitor] (const Expression_Tree &t) { t.accept(print_visitor);}); for (auto &iter : expr_tree) iter.accept(print_visitor);
44 See en.wikipedia.org/wiki/C++11 for info on C++11
Douglas C. Schmidt
Java Pattern-Oriented Language/Library Features

ExpressionTree exprTree = ; ETVisitor printVisitor = new PrintVisitor(); for (ComponentNode node : exprTree) node.accept(printVisitor); Java for-each loop (assumes tree implements Iterable)
45
Douglas C. Schmidt
Java Pattern-Oriented Language/Library Features

ExpressionTree exprTree = ; ETVisitor printVisitor = new PrintVisitor(); for (ComponentNode node : exprTree) node.accept(printVisitor); for (Iterator<ExpressionTree> itr = exprTree.iterator(); itr.hasNext(); ) iter.next().accept (printVisitor);
Java iterator style
46
Douglas C. Schmidt
OO designs are characterized by structuring software architectures around objects/classes in domains Rather than on actions performed by the software
Summary
<< accept >>
ET_Visitor
Evaluation_Visitor
Print_Visitor
Expression_Tree << create >>
Component_Node
ET_Iterator
ET_Iterator_Impl
LQueue
Level_Order_ET _Iterator_Impl In_Order_ET _Iterator_Impl Post_Order_ET _Iterator_Impl Pre_Order_ET _Iterator_Impl
std::stack
47
Douglas C. Schmidt
Summary
Systems evolve & functionality changes, but well-defined objects & class roles & relationships are often relatively stable over time
48
Douglas C. Schmidt
Summary
Expression_Tree
Component_Node
Systems evolve & functionality changes, but well-defined objects & class roles & relationships are often relatively stable over time To obtain flexible & reusable software, therefore, its better to base the structure on objects/classes rather than on actions
Leaf_Node
49

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques Present an OO design for the expression tree processing app Summarize the patterns in the expression tree design
Design Problem Extensible expression tree structure Encapsulating variability & simplifying memory management Parsing expressions & creating expression tree Extensible expression tree operations Implementing STL iterator semantics Consolidating user operations Consolidating creation of variabilities for commands, iterators, etc. Ensuring correct protocol for commands Structuring the application event flow Supporting multiple operation modes Centralizing access to global resources Eliminating loops via the STL std::for_each() algorithm Pattern(s) Composite Bridge Interpreter & Builder Iterator & Visitor Prototype Command Abstract Factory & Factory Method State Reactor Template Method & Strategy Singleton Adapter
51
Douglas C. Schmidt
Outline of the Design Space for GoF Patterns

Abstract the process of instantiating objects Describe how classes & objects can be combined to form larger structures
Purpose: Reflects What the Pattern Does
Concerned with communication between objects
Creational Class Scope: Domain Where Pattern Applies Object Factory Method Abstract Factory Builder Prototype Singleton
Structural Adapter (class) Adapter (object) Bridge Composite Decorator Flyweight Faade Proxy
Behavioral Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor
en.wikipedia.org/wiki/Design_Patterns52 has info on Gang of Four (GoF) book
Douglas C. Schmidt
Design Problems & Pattern-Oriented Solutions

Binary Nodes
Design Problem Extensible expression tree structure Encapsulating variability & simplifying memory management Parsing expressions & creating expression tree Extensible tree operations Implementing STL iterator semantics Consolidating user operations
Pattern(s) Composite Bridge
Interpreter & Builder Iterator & Visitor Prototype Command
Consolidating creation of Abstract Factory variabilities for commands, & Factory iterators, etc. Method
53
Douglas C. Schmidt

Binary Nodes
54
Douglas C. Schmidt

Binary Nodes
55
Douglas C. Schmidt

Binary Nodes
56
Douglas C. Schmidt

Binary Nodes
57
Douglas C. Schmidt

Binary Nodes
58
Douglas C. Schmidt

Binary Nodes
59
Douglas C. Schmidt

Binary Nodes
Design Problem
Pattern(s)
Ensuring correct protocol State for processing commands Structuring the application event flow Reactor Template Method & Strategy Singleton Adapter
Supporting multiple operation modes Centralizing access to global resources Eliminating loops via the STL std::for_each() algorithm
60
Douglas C. Schmidt

Binary Nodes
Design Problem
Pattern(s)
61 See www.dre.vanderbilt.edu/~schmidt/PDF/Reactor.pdf for the Reactor pattern
Douglas C. Schmidt

Binary Nodes
Design Problem
Pattern(s)
62
Douglas C. Schmidt

Binary Nodes
Design Problem
Pattern(s)
63
Douglas C. Schmidt

Binary Nodes
Design Problem
Pattern(s)
64 Naturally, these patterns apply to more than expression tree processing apps!
Douglas C. Schmidt
GoF patterns provide elements of reusable object-oriented software that address limitations with algorithmic decomposition
Summary
65
A Case Study of Gang of Four (GoF) Patterns : Part 5

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques Present an OO design for the expression tree processing app Summarize the patterns in the expression tree design Explore patterns for Tree structure & access
Component_Node Expression_Tree
Leaf_Node
67
Douglas C. Schmidt
Overview of Tree Structure & Access Patterns

P urpose: Define the key internal data structure for the expression tree & simplify access to this data structure
Expression_Tree
Component_Node
Leaf_Node
Composite_ Add_Node
Bridge
Composite 68
Douglas C. Schmidt
Problem: Extensible Expression Tree Structure

Goals Support physical structure of expression tree e.g., binary/unary operators & operands
69
Douglas C. Schmidt

Goals Support physical structure of expression tree e.g., binary/unary operators & operands Provide hook methods that enable arbitrary operations on tree nodes
Operation 1: Print all the values of the nodes in the tree Operation 2: Evaluate the yield of the nodes in the tree
70
Douglas C. Schmidt

Goals Support physical structure of expression tree e.g., binary/unary operators & operands Provide hook methods that enable arbitrary operations on tree nodes Constraints/forces Treat operators & operands uniformly No distinction between one vs. many to avoid special cases
71 Eliminate need for type tags & switch statements, cf. algorithmic decomposition
Douglas C. Schmidt
Solution: Recursive Structure

Model an expression tree as a recursive collection of nodes
72
Douglas C. Schmidt

Model an expression tree as a recursive collection of nodes Nodes are represented in a hierarchy that captures properties of each node, e.g.: Leaf nodes contain no children
73
Douglas C. Schmidt

Model an expression tree as a recursive collection of nodes Nodes are represented in a hierarchy that captures properties of each node, e.g.: Leaf nodes contain no children Unary nodes recursively contain one other child node
74
Douglas C. Schmidt

Model an expression tree as a recursive collection of nodes Nodes are represented in a hierarchy that captures properties of each node, e.g.: Leaf nodes contain no children Unary nodes recursively contain one other child node Binary nodes recursively contain two other child nodes
75
Douglas C. Schmidt
Component_Node Class Interface

Abstract base class for composable expression tree node objects Interface virtual virtual int virtual Component_Node * virtual Component_Node * virtual void
Virtual destructor ensures nodes are all deleted properly
~Component_Node()=0 item() const left() const right() const accept(ET_Visitor &visitor) const
This hook method plays an essential role in I terator & Visitor patterns (covered later)
Subclasses Leaf_Node, Composite_Unary_Node, Composite_Binary_Node, etc.
Commonality: Base class interface used by all nodes in an expression tree Variability: Each subclass defines state & method implementations that
are specific for the various types of nodes 76
Douglas C. Schmidt
Component_Node Class Hierarchy

Note the inherent recursion in this hierarchy
Component_Node e.g., Leaf_Node is a Component_Node
Leaf_Node
e.g., Composite_Unary_Node is a Component_Node & also has a Component_Node
Composite_ Add_Node e.g., Composite_Binary_Node is a Composite_Unary_Node & also has a Component_Node Composite_ Multiply_Node
Eliminates need for type tags & switch 77 statements by treating nodes uniformly!
Douglas C. Schmidt
Composite
Intent Applicability Objects must be composed recursively
GoF Object structural
Treat individual objects & multiple, recursively-composed objects uniformly
and no distinction between individual & composed elements and objects in structure can be treated uniformly Structure
e.g., Component_Node
e.g., Leaf_Node
e.g., Composite_Unary_Node, Composite_Binary_Node, Composite_Add_Node, etc.
78
Douglas C. Schmidt
Composite
Composite example in C++
Build an expression tree based on recursively-composed objects Component_Node *l1 = new Leaf_Node(5); Component_Node *l2 = new Leaf_Node(3); Component_Node *l3 = new Leaf_Node(4);
l1
l2
l3
79
Douglas C. Schmidt
Composite
Build an expression tree based on recursively-composed objects Component_Node *l1 = new Leaf_Node(5); Component_Node *l2 = new Leaf_Node(3); u1 Component_Node *l3 = new Leaf_Node(4); Component_Node *u1 = new Composite_Negate_Node(l1); Component_Node *b1 = new Composite_Add_Node(l2, l3);
b1
l1
l2
l3
80
Douglas C. Schmidt
Composite
Build an expression tree based on recursively-composed objects Component_Node *l1 = new Leaf_Node(5); Component_Node *l2 = new Leaf_Node(3); u1 Component_Node *l3 = new Leaf_Node(4); Component_Node *u1 = new Composite_Negate_Node(l1); Component_Node *b1 = new Composite_Add_Node(l2, l3); Component_Node *b2 = new Composite_Multiply_Node(u1, b1); b2
b1
l1
l2
l3
In C++ we need to consider how to 81 manage dynamically allocated memory
Douglas C. Schmidt
Composite
Composite example in Java
Build an expression tree based on recursively-composed objects ComponentNode l1 = new LeafNode(5); ComponentNode l2 = new LeafNode(3); u1 ComponentNode l3 = new LeafNode(4); ComponentNode u1 = new CompositeNegateNode(l1); ComponentNode b1 = new CompositeAddNode(l2, l3); ComponentNode b2 = new CompositeMultiplyNode(u1, b1); b2
b1
l1
l2
l3
82 Javas garbage collection handles dynamically allocated memory automatically
Douglas C. Schmidt
Composite
Consequences + Uniformity: Treat components the same regardless of complexity & behavior + Extensibility: New component subclasses work wherever existing ones do
+ Parsimony: Classes only include fields they need Perceived complexity: May need what seems like a prohibitive numbers of classes/objects Awkward designs: May need to treat leaves as lobotomized composites in some cases
83
Douglas C. Schmidt
Composite
Consequences + Uniformity: Treat components the same regardless of complexity & behavior
+ Extensibility: New Component subclasses work wherever existing ones do + Parsimony: Classes only include fields they need Perceived complexity: May need what seems like a prohibitive numbers of classes/objects Awkward designs: May need to treat leaves as lobotomized composites in some cases Implementation Do components know their parents? Uniform interface for both leaves & composites? Dont allocate storage for children in component base class (big problem with algorithmic decomposition solution)
84 Who is responsible for deleting children?
Douglas C. Schmidt
Composite
Consequences + Uniformity: Treat components the same regardless of complexity & behavior

Known Uses ET++ Vobjects InterViews Glyphs, Styles Unidraw Components, MacroCommands Directory structures on UNIX & Windows Naming Contexts in CORBA Internal representations of MIME types
+ Extensibility: New Component subclasses work wherever existing ones do + Parsimony: Classes only include fields they need Perceived complexity: May need what seems like a prohibitive numbers of classes/objects Awkward designs: May need to treat leaves as lobotomized composites in some cases Implementation Do components know their parents? Uniform interface for both leaves & composites?
Dont allocate storage for children in component base class (big problem with algorithmic decomposition solution)
85 Who is responsible for deleting children?
Douglas C. Schmidt
Problem: Encapsulating Variability & Simplifying Memory Management

Goals Help encapsulate sources of variability in expression tree construction & use
Expression_Tree expr_tree (new Composite_Add_Node (new Leaf_Node (3), new Leaf_Node (4)));
Hide complex recursive internal structure behind a simple interface
86
Douglas C. Schmidt

Print_Visitor print_visitor; for (auto iter = expr_tree.begin(); iter != expr_tree.end(); ++iter) Iterate through all elements in expression tree without concern (*iter).accept(print_visitor); for how tree is structured or what traversal has been designated
87
Douglas C. Schmidt

Print_Visitor print_visitor; for (auto iter = expr_tree.begin(); iter != expr_tree.end(); ++iter) Note how C++11 auto keyword can deduce type of Expression (*iter).accept(print_visitor);
_Tree iterator
88
Douglas C. Schmidt

Goals Help encapsulate sources of variability in expression tree construction & use Simplify memory management e.g., minimize use of naked pointers in C++ app code to avoid memory leaks stemming from exceptions
Component_Node *l1 = new Leaf_Node(5); Component_Node *l2 = new Leaf_Node(3); Component_Node *l3 = new Leaf_Node(4); Component_Node *u1 = new Composite_Negate_Node(l1); Component_Node *b1 = new Composite_Add_Node(l2, l3); Component_Node *b2 = new Composite_Multiply_Node(u1, b1); ... delete b2;
This is just asking for trouble in C++!
89
Douglas C. Schmidt

Goals
class Pre_Order_ET_Iterator_Impl : public ET_Iterator_Impl { public: Pre_Order_ET_Iterator_Impl Simplify memory management (const Expression_Tree &root) { stack_.push(root); e.g., minimize use of naked } pointers in C++ app code Need to optimize this to avoid memory leaks operation to avoid overhead stemming from exceptions of deep copies Constraints/forces // ... Account for the fact that STL private: algorithms & iterators have std::stack<Expression_Tree> stack_; value semantics }; 90
Help encapsulate sources of variability in expression tree construction & use
Douglas C. Schmidt
Solution: Decouple Interface & Implementation(s)

Create an interface class (Expression_Tree) used by clients
Expression _Tree
91
Douglas C. Schmidt

Create an interface class (Expression_Tree) used by clients & an implementor hierarchy (Component_Node et al) that encapsulates variability
Interface class can use a C++ std::shared_ptr reference count object to help automate memory management
Expression _Tree
Component _Node
Leaf_Node
Composite_ Binary_Node
Composite_ Negate_Node
Composite_ Add_Node
92
Douglas C. Schmidt

Create an interface class (Expression_Tree) used by clients & an implementor hierarchy (Component_Node et al) that encapsulates variability
Expression _Tree
Component _Node
Leaf_Node
The Abstract Factory pattern can be used to produce the right implementor hierarchy (as seen later)
Composite_ Add_Node
93
Douglas C. Schmidt
Expression_Tree Class Interface

Interface for composite structure that contains all nodes in expression tree Interface
Manage reference counts typedef ET_Iterator iterator ... Expression_Tree(Component_Node *root) Expression_Tree(const Expression_Tree &t) operator=(const Expression_Tree &t) ~Expression_Tree() Plays essential role in is_null() const I terator & Visitor item() const patterns (covered later) left() right() accept(ET_Visitor &visitor) begin(const std::string &order = "") end(const std::string &order = "") begin(const std::string order = "") const end(const std::string &order = "") const
void
bool const int Expression_Tree Expression_Tree Forward to void implementor iterator hierarchy iterator const_iterator const_iterator
94
Douglas C. Schmidt
Expression_Tree Class Interface

Interface for composite structure that contains all nodes in expression tree Interface
Iterator trait void bool const int Expression_Tree Expression_Tree void Iterator iterator factories iterator const_iterator const_iterator typedef ET_Iterator iterator ... Expression_Tree(Component_Node *root) Expression_Tree(const Expression_Tree &t) operator=(const Expression_Tree &t) ~Expression_Tree() is_null() const item() const left() right() accept(ET_Visitor &visitor) begin(const std::string &order = "") end(const std::string &order = "") begin(const std::string order = "") const end(const std::string &order = "") const
Commonality: Provides common interface for expression tree operations Variability: The contents of the composite nodes in the expression tree
will vary depending on the user input expression 95
Douglas C. Schmidt
Bridge
Intent
GoF Object Structural
Separate an interface from its implementation(s) Applicability When interface & implementation should vary independently Require a uniform interface to interchangeable implementor hierarchies Structure
e.g., Expression_Tree e.g., Component_Node
e.g., Composite_Unary_Node, Composite_Binary_Node , etc. 96
Douglas C. Schmidt
Bridge
Bridge example in C++
Separate expression tree interface from the composite node implementations class Expression_Tree { root_ manages lifecycle of pointer parameter public: Expression_Tree(Component_Node *root): root_(root) {}
Interface forwards to implementor via shared_ptr
... void accept(ET_Visitor &v) { root_->accept(v); } private: std::shared_ptr <Component_Node> root_;

C++11/Boost smart pointer that handles reference counting
97 See en.wikipedia.org/wiki/Smart_pointer#shared_ptr_and_weak_ptr for more
Douglas C. Schmidt
Bridge
Bridge example in C++
Separate expression tree interface from the composite node implementations class Expression_Tree { public: Expression_Tree(Component_Node *root): root_(root) {} ... void accept(ET_Visitor &v) { root_->accept(v); } private: std::shared_ptr <Component_Node> root_; ...
expr_tree manages lifecycle of composite via Bridge pattern
Expression_Tree expr_tree (new Composite_Multiply_Node(u1, b1));

98
Douglas C. Schmidt
Bridge
Consequences + Abstraction interface & implementor hierarchy are decoupled + Implementors can vary dynamically + Enables efficient use of value-based STL algorithms & containers
One-size-fits-all abstraction & implementor interfaces
99
Douglas C. Schmidt
Bridge
One-size-fits-all abstraction & implementor interfaces Implementation
Sharing implementors & reference counting

e.g., C++11/Boost shared_ptr
Creating the right implementor Often addressed by using factories Not as widely used in Java as in C++
100
Douglas C. Schmidt
Bridge

Known Uses
ET++ Window/WindowPort libg++ Set/{LinkedList,

HashTable}
AWT Component/
ComponentPeer
One-size-fits-all abstraction & implementor interfaces Implementation
Java Socket/SocketImpl ACE Reactor framework
Sharing implementors & reference counting

e.g., C++11/Boost shared_ptr
Creating the right implementor Often addressed by using factories Not as widely used in Java as in C++
101
Douglas C. Schmidt
Summary of Tree Structure & Access Patterns

Composite is used to define internal data structure for the expression tree processing app & Bridge simplifies access to this data structure for C++ code
Expression_Tree
Component_Node
Leaf_Node
Composite_ Add_Node
Bridge
Composite
102 of a pattern compound Bridge Composite is an example

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques Present an OO design for the expression tree processing app Summarize the patterns in the expression tree design Explore patterns for Tree structure & access Tree creation
Number Operator Unary_Operator
In_Order_ Uninitialized_ State make_tree() ET_Interpreter _Context
ET_Interpreter
Symbol
Add
Subtract
Negate
Multiply
Divide
104
Douglas C. Schmidt
Overview of Tree Creation Patterns

P urpose: Parse user input expresion & create the internal data structure for the expression tree
Expression_Tree ET_Context ET_Interpreter_Context
Interpreter
<< use >>
ET_Interpreter << build >> Component_Node Symbol
Leaf_Node
Composite_ Unary_Node <<build>>
Number
Operator
Unary_Operator
Composite_ Add_Node
Add
Subtract
Negate
<<build>>
Multiply
Divide
Composite
Builder
105 of patterns involved in this design There are many classes, but only a handful
Douglas C. Schmidt
Problem: Parsing Expressions & Creating an Expression Tree

Goals Simplify & centralize the creation of all nodes in the composite expression tree
in-order expression
= -5*(3+4)
106
Douglas C. Schmidt

Goals Simplify & centralize the creation of all nodes in the composite expression tree Be extensible for future types of expression formats & optimizations pre-order expression = *-5+34 post-order expression = 5-34+* level-order expression = *-+534 in-order expression = -5*(3+4)
107
Douglas C. Schmidt

Goals Simplify & centralize the creation of all nodes in the composite expression tree Be extensible for future types of expression formats & optimizations Constraints/forces Dont recode existing clients when new types of expression formats are added Add new user input expressions without recompiling existing code
108
pre-order expression = *-5+34 post-order expression = 5-34+* level-order expression = *-+534 in-order expression = -5*(3+4)
Douglas C. Schmidt
Solution: Build Expression Tree Using Interpreter

Use an interpreter to create a parse tree corresponding to user input expression
ET_Interpreter In_Order_ Uninitialized_ State make_tree()
Symbol
ET_Interpreter _Context
Operator
Unary_Operator
Multiply
Negate
Number
Add
109
Douglas C. Schmidt
Solution: Build Expression Tree Using Interpreter

Use an interpreter to create a parse tree corresponding to user input expression This parse tree is then traversed to build the appropriate type of nodes in the corresponding
ET_Interpreter In_Order_ Uninitialized_ State make_tree()
Symbol
ET_Interpreter _Context
expression tree
Operator
Unary_Operator
We create the entire parse tree to enable optimizations (as a future extension)
Multiply
Negate
Number
Add
<<build>>
110
Douglas C. Schmidt
ET_Interpreter Class Interface

Transforms expressions into a parse tree & then generates the
corresponding expression tree
Interface virtual ~ET_Interpreter() Expression_Tree interpret(ET_Interpreter_Context &context, const std::string &input) <<uses>> ET_Interpreter_Context() ~ET_Interpreter_Context() int get(std::string variable) void set(std::string variable, int value) void print() The context can be used to implement void reset() setters/getters for variable leaf nodes
111
Douglas C. Schmidt

Interface virtual ~ET_Interpreter() Expression_Tree interpret(ET_Interpreter_Context &context, const std::string &input) <<creates>>
Abstract base class of all parse tree nodes
Symbol(Symbol *left, Symbol *right) virtual ~Symbol() virtual int precedence()=0 virtual Component_Node * build()=0
This method is used to build a component node corresponding to the expression parse tree node 112
Douglas C. Schmidt

Interface virtual ~ET_Interpreter() Expression_Tree interpret(ET_Interpreter_Context &context, const std::string &input) <<uses>> ET_Interpreter_Context() <<creates>> ~ET_Interpreter_Context() Symbol(Symbol *left, int get(std::string variable) Symbol *right) void set(std::string variable, virtual ~Symbol() int value) virtual int precedence()=0 void print() virtual void reset() Component_Node * build()=0
Commonality: Provides a common interface building parse trees &

expression trees from user input expressions
Variability: The structure of the parse trees & expression trees can vary
depending on the format & contents of the expression input 113
Douglas C. Schmidt
Interpreter
Intent
GoF Class Behavioral
Given a language, define a representation for its grammar, along with an interpreter that uses the representation to interpret sentences in the language Applicability When the grammar is simple & relatively stable When time/space efficiency is not a critical concern Structure
e.g., Symbol
e.g., Number or Variable
e.g., operators like Add, Subtract, Multiply, Divide, etc.
114
Douglas C. Schmidt
Interpreter
Interpreter example in C++ The interpret() method creates a parse tree from users expression input
Expression_Tree ET_Interpreter::interpret (ET_Interpreter_Context &context, const std::string &input) { std::list<Symbol *> parse_tree; Symbols added to parse tree as ... interpreter recognizes them if(is_number(input[i])){ Handle operand number_insert(input, parse_tree); } else if(input[i] == '+'){ Handle addition operator Add *op = new Add(); op->add_precedence(accum_precedence); precedence_insert(op, parse_tree); ... } else if(input[i] == '(') { Handle parenthesized expression handle_parenthesis(context, input, accum_precedence, parse_tree); } 115 ...
Douglas C. Schmidt
Interpreter
Consequences
+ Simple grammars are easy to change & extend e.g., All rules represented by distinct classes in a consistent & orderly manner + Adding another rule adds another class Complex grammars hard to create & maintain e.g., More inter-dependent rules yield more inter-dependent classes
116 approach (e.g., parser generators) Complex grammars may require different
Douglas C. Schmidt
Interpreter
Consequences
+ Simple grammars are easy to change & extend e.g., All rules represented by distinct classes in a consistent & orderly manner + Adding another rule adds another class Complex grammars hard to create & maintain e.g., More inter-dependent rules yield more inter-dependent classes Implementation Express language rules, one per class Literal translations expressed as terminal
expressions
Alternations, repetitions, or sequences expressed as nonterminal expresssions

117
Douglas C. Schmidt
Interpreter
Consequences

Known Uses Text editors & web browsers use Interpreter to lay out documents & check spelling e.g., an equation in TeX is represented as a tree where internal nodes are operators & leaves are variables Smalltalk compilers The QOCA constraintsolving toolkit
+ Simple grammars are easy to change & extend e.g., All rules represented by distinct classes in a consistent & orderly manner + Adding another rule adds another class Complex grammars hard to create & maintain e.g., More inter-dependent rules yield more inter-dependent classes Implementation Express language rules, one per class Literal translations expressed as terminal
expressions
Alternations, repetitions, or sequences expressed as nonterminal expresssions

118
Douglas C. Schmidt
Builder
Intent
GoF Object Creational
Separate the construction of a complex object from its representation so that the same construction process can create different representations Applicability Need to isolate knowledge of the creation of a complex object from its parts Need to allow different implementations/interfaces of an object's parts Structure
e.g., Symbol e.g., Leaf_Node, Composite_Add _Node, etc.
e.g., ET_Interpreter
e.g., Number, Subtract, Add, Multiply, etc.
119
Douglas C. Schmidt
Builder
Builder example in C++ The interpret() method builds composite expression tree from parse tree
Expression_Tree ET_Interpreter::interpret (ET_Interpreter_Context &context, const std::string &input) { ... return Expression_Tree(parse_tree.back()->build()); Invoke a recursive expression tree build, starting with the root symbol in parse tree created by the interpreter
120
Douglas C. Schmidt
Builder
Builder example in C++ The interpret() method builds composite expression tree from parse tree
Expression_Tree ET_Interpreter::interpret (ET_Interpreter_Context &context, const std::string &input) { ... return Expression_Tree(parse_tree.back()->build());
Component_Node * Multiply::build() { return new Composite_Multiply_Node (left_->build(), right_->build()); } Build equivalent component nodes Component_Node *Number::build() { return new Leaf_Node(item_); } 121
Douglas C. Schmidt
Builder
Consequences + Isolates code for construction & representation
+ Can vary a product's internal representation
+ Finer control over the construction process May involve a lot of classes
122
Douglas C. Schmidt
Builder
+ Finer control over the construction process May involve a lot of classes Implementation The Builder pattern is a factory pattern with a mission A Builder pattern implementation exposes itself as a factory It goes beyond conventional factory patterns by connecting various implementations together
123
Douglas C. Schmidt
Builder

Known Uses ET++ RTF converter application Smalltalk-80 ACE Service Configurator framework
+ Finer control over the construction process May involve a lot of classes Implementation The Builder pattern is a factory pattern with a mission A Builder pattern implementation exposes itself as a factory It goes beyond conventional factory patterns by connecting various implementations together
124
Douglas C. Schmidt
Summary of Tree Creation Patterns

Interpreter & Builder patterns create internal data
structure for expression tree from user input
Expression_Tree ET_Context
Interpreter
<< use >> ET_Interpreter_Context
ET_Interpreter << build >> Component_Node Symbol
Leaf_Node
Composite_ Unary_Node <<build>>
Number
Operator
Unary_Operator
Composite_ Add_Node
Add
Subtract
Negate
<<build>>
Multiply
Divide
Composite
Builder
Interpreter, Builder, & Composite125 are powerful pattern sequence

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques Present an OO design for the expression tree processing app Summarize the patterns in the expression tree design Explore patterns for Tree structure & access Tree creation Tree traversal for (auto iter = expr_tree.begin(); iter != expr_tree.end(); ++iter) (*iter).accept(print_visitor);
127
Douglas C. Schmidt
Overview of Tree Traversal Patterns

P urpose: Traverse the expression tree & perform designated operations
<< accept >>
Visitor
ET_Visitor
Expression_Tree
Component_Node
Iterator
<< create >> Evaluation_Visitor Print_Visitor
ET_Iterator
ET_Iterator_Impl
std::queue
Level_Order_ET _Iterator_Impl In_Order_ET_ Iterator_Impl Post_Order_ ET_Iterator_Impl Pre_Order_ET _Iterator_Impl std::stack
Prototype
128 Patterns decouple expression tree structure from operations performed on it
Douglas C. Schmidt
Goals
Problem: Extensible Expression Tree Operations

Operation 2: Evaluate the yield of the nodes in the tree Operation 1: Print all the values of the nodes in the tree
Create a framework for performing operations that affect nodes in a tree
Binary Nodes
Unary Node Leaf Nodes 129
Douglas C. Schmidt
Goals
Problem: Extensible Expression Tree Operations

Operation 2: Evaluate the yield of the nodes in the tree Operation 1: Print all the values of the nodes in the tree
Create a framework for performing operations that affect nodes in a tree Constraints/forces Support multiple operations on the expression tree without tightly coupling operations with the tree structure i.e., dont have print() & evaluate() methods in the node classes
Unary Node
Binary Nodes
Leaf Nodes 130
Douglas C. Schmidt
Solution (Part A): Encapsulate Traversal

Iterator Encapsulates a traversal algorithm without exposing representation details to callers e.g., in-order iterator = -5*(3+4) pre-order iterator = *-5+34 post-order iterator = 5-34+* level-order iterator = *-+534
Unary Node
Leaf for (auto iter = expr_tree.begin(); Nodes iter != expr_tree.end(); ++iter) (*iter).accept(print_visitor);
131
Douglas C. Schmidt
Solution (Part A): Encapsulate Traversal

Iterator Encapsulates a traversal algorithm without exposing representation details to callers e.g., in-order iterator = -5*(3+4) pre-order iterator = *-5+34 post-order iterator = 5-34+* level-order iterator = *-+534 Iterator Structure
ET_Iterator ET_Iterator_Impl

Post_Order_ET_Iterator_Impl Pre_Order_ET_Iterator_Impl
In_Order_ET_Iterator_Impl Level_Order_ET_Iterator_Impl
132& simplifies memory management Bridge pattern encapsulates variability
Douglas C. Schmidt
ET_Iterator Class Interface

Interface for iterator that traverses all nodes in an expression tree instance
Interface
This interface plays the role of the abstraction in the Bridge pattern
Expression_Tree const Expression_Tree ET_Iterator & ET_Iterator bool bool
ET_Iterator(ET_Iterator_Impl *) ET_Iterator(const ET_Iterator &) operator *() operator *() const operator++() operator++(int) operator==(const ET_Iterator &rhs) operator!=(const ET_Iterator &rhs) ...
Overloaded C++ operators conform to whats expected from an STL iterator
Commonality: Provides a common interface for expression tree iterators

that conforms to the standard STL iterator interface
Variability: Can be configured with specific expression tree iterator algorithms via the Abstract Factory 133 pattern
Douglas C. Schmidt
ET_Iterator_Impl Class Interface

iterations algorithms that can be performed to traverse the expression tree ET_Iterator_Impl Interface (const Expression_Tree &) virtual ~ET_Iterator_Impl() virtual Expression_Tree operator *()=0 virtual void operator++()=0 This class virtual bool operator== doesnt need (const ET_Iterator_Impl &)=0 to mimic the virtual bool operator!= Bridge interface (const ET_Iterator_Impl &)=0 virtual ET_Iterator_Impl * clone()=0
clone() is used by P rototype pattern
Base class of the iterator implementor hierarchy that defines the various
Commonality: Provides a common interface for implementing expression

tree iterators that conforms to the standard STL iterator interface nodes in the expression trees in a particular traversal order 134
Variability: Can be subclassed to define various algorithms for accessing
Douglas C. Schmidt
Iterator
GoF Object Behavioral
Intent Access elements of an aggregate without exposing its representation Applicability Require multiple traversal algorithms over an aggregate Require a uniform traversal interface over different aggregates When aggregate classes & traversal algorithm must vary independently Structure
e.g., Expression_Tree e.g., ET_Iterator_Impl
e.g., Pre_Order_ET_Iterator_Impl, In_Order_ET_Iterator_Impl, etc. 135
Douglas C. Schmidt
Iterator
Comparing STL iterators with GoF iterators
STL iterators have value-semantics, e.g.:

for (auto iter = expr_tree.begin(); iter != expr_tree.end(); ++iter) (*iter).accept(print_visitor);
Easy to use, harder to implement
In contrast, GoF iterators have pointer semantics, e.g.:

Iterator *iter; Easy to implement, harder to use (correctly)
for (iter = exprTree.createIterator(); iter->done() == false; iter->advance()) iter->currentElement()->accept(printVisitor); delete iter; 136 The Bridge pattern enables STL iterator use in expression tree processing app
Douglas C. Schmidt
Iterator
Comparing Java iterators with GoF iterators
Java iterators are closer to GoF iterators than STL iterators are, e.g.:
for (IteratorL<ExpressionTree> itr = exprTree.iterator(); itr.hasNext(); ) iter.next().accept (printVisitor); }
Heres the equivalent Java code for GoF-style iterators, e.g.:

for (ETIterator iter = tree.createIterator(); !iter.done(); iter.advance()) (iter.currentElement()).accept(printVisitor);
137 in C++/Java is to use a for loop Often, the simplest way to use an iterator
Douglas C. Schmidt
Iterator
for loop, e.g.:
Comparing Java iterators with STL iterators
Often, the simplest way to use an iterator in C++/Java is to use a

C++11 range-based for loop for (auto &iter : expr_tree) iter.accept(print_visitor);
Java for-each loop for (ComponentNode node : exprTree) node.accept(printVisitor);
138
Douglas C. Schmidt
Iterator
Iterator example in C++
An STL std::stack can be used to traverse an expression tree in pre-order

class Pre_Order_ET_Iterator_Impl : public ET_Iterator_Impl { public: Pre_Order_ET_Iterator_Impl(const Expression_Tree &root) { stack_.push (root); } Begin the iteration virtual Expression_Tree operator*() { return stack_.top (); } virtual void operator++() { Return current item if (!stack_.is_empty()) { Expression_Tree current = stack_.top(); stack_.pop(); if (!current.right().is_null()) stack_.push(current.right()); Advance one item if (!current.left().is_null()) stack_.push(current.left()); } } The use of a stack simulates recursion, one item at a time 139 ...
Douglas C. Schmidt
Iterator
Consequences + Flexibility: Aggregate & traversal are independent
+ Multiplicity: Multiple iterators & multiple traversal algorithms Overhead: Additional communication between iterator & aggregate Particularly problematic for iterators in concurrent or distributed systems
140
Douglas C. Schmidt
Iterator
+ Multiplicity: Multiple iterators & multiple traversal algorithms Overhead: Additional communication between iterator & aggregate Particularly problematic for iterators in concurrent or distributed systems Implementation Internal vs. external iterators Violating the object structures encapsulation Robust iterators Synchronization overhead in multi-threaded programs
141 Batching in distributed & concurrent programs
Douglas C. Schmidt
Iterator

Known Uses C++ STL iterators JDK Enumeration, Iterator Unidraw Iterator C++11 range-based for loops & Java foreach loops
+ Multiplicity: Multiple iterators & multiple traversal algorithms Overhead: Additional communication between iterator & aggregate Particularly problematic for iterators in concurrent or distributed systems Implementation Internal vs. external iterators Violating the object structures encapsulation Robust iterators Synchronization overhead in multi-threaded programs
142 Batching in distributed & concurrent programs
Douglas C. Schmidt
Solution (Part B): Decouple Operations from Expression Tree Structure

Visitor Defines action(s) at each step of traversal & avoids hard-coding action(s) into nodes
143
Douglas C. Schmidt

Visitor Defines action(s) at each step of traversal & avoids hard-coding action(s) into nodes Iterator calls accept(ET_Visitor&) method on each node in expression tree
Unary for (auto iter = expr_tree.begin(); Node
iter != expr_tree.end(); ++iter) (*iter).accept(print_visitor);
Leaf Nodes
144
Douglas C. Schmidt

Visitor Defines action(s) at each step of traversal & avoids hard-coding action(s) into nodes Iterator calls accept(ET_Visitor&) method on each node in expression tree
Unary for (auto iter = expr_tree.begin(); Node
iter != expr_tree.end(); ++iter) (*iter).accept(print_visitor); accept() calls back on visitor, e.g.: void Leaf_Node::accept(ET_Visitor &v) { v.visit(*this); }
Leaf Nodes
145 Note static polymorphism based on method overloading by type
Douglas C. Schmidt
ET_Visitor Class Interface

Interface for a visitor that defines operations performed for each type of
node in the expression tree Interface virtual virtual virtual virtual virtual virtual void void void void void void
An overloaded visit() method is defined for each Component_Node subclass
visit(const visit(const visit(const visit(const visit(const visit(const
Leaf_Node &node)=0 Composite_Negate_Node &node)=0 Composite_Add_Node &node)=0 Composite_Subtract_Node &node)=0 Composite_Divide_Node &node)=0 Composite_Multiply_Node &node)=0
Commonality: Provides a common accept()method for all expression

tree nodes & common visit()method for all visitor subclasses
ET_Visitor
Variability: Can be subclassed

to define specific behaviors for the visitors & nodes
146
Evaluation_Visitor
Print_Visitor
Douglas C. Schmidt
Visitor
Intent
Centralize operations on an object structure so that they can vary independently, but still behave polymorphically Applicability When classes define many unrelated operations Class relationships in structure rarely change, but operations on them change Algorithms keep state thats updated during traversal Structure
e.g., ET_Visitor e.g., Composite_Add_Node , Composite_ . Binary_Node, Composite_Unary_Node, etc. e.g., Evaluation_Visitor, Print_Visitor, etc. e.g., Component_Node
147
Douglas C. Schmidt
Visitor
Visitor implementation in C++
The Print_Visitor class prints character code or value for each node
class Print_Visitor : public ET_Visitor { public: virtual void visit(const Leaf_Node &); virtual void visit(const Add_Node &); virtual void visit(const Divide_Node &); // etc. for all relevant Component_Node subclasses };
148
Douglas C. Schmidt
Visitor
The Print_Visitor class prints character code or value for each node
class Print_Visitor : public public: virtual void visit(const virtual void visit(const virtual void visit(const // etc. }; ET_Visitor { Leaf_Node &); Add_Node &); Divide_Node &);
Can be combined with any traversal algorithm, e.g.:

Print_Visitor print_visitor; for (auto iter = expr_tree.begin("post-order"); iter != exor_tree.end("post-order"); ++iter) (*iter).accept(print_visitor); calls visit(*this) 149
Douglas C. Schmidt
Visitor
Visitor implementation in C++ The iterator controls the order in which accept() is called on each node in the composition accept() then visits the node to perform the desired print action
Iterator Leaf_Node(5) Composite_Negate_Node print_visitor
accept(print_visitor)
cout<< node.item();
accept(print_visitor)
cout<< -
150
Douglas C. Schmidt
Visitor
Visitor implementation in C++ The Evaluation_Visitor class evaluates nodes in an expression tree traversed using a post-order iterator e.g., 5-34+*

class Evaluation_Visitor : public ET_Visitor { public: virtual void visit (const Leaf_Node &); virtual void visit (const Add_Node &); virtual void visit (const Divide_Node &); // etc.
};
151
Douglas C. Schmidt
Visitor
Visitor implementation in C++ The Evaluation_Visitor class evaluates nodes in an expression tree traversed using a post-order iterator e.g., 5-34+*

class Evaluation_Visitor : public ET_Visitor { public: virtual void visit (const Leaf_Node &); virtual void visit (const Add_Node &); virtual void visit (const Divide_Node &); // etc. private: std::stack<int> stack_; }; push(node.item()) push(-pop()) push(node.item()) push(node.item()) push(pop()+pop()) push(pop()*pop())
1. S = [5] 2. S = [-5] 3. S = [-5, 3] It uses a stack to keep track of the post-order expression tree value that 4. S = [-5, 3, 4] 5. S = [-5, 7] has been processed thus far during 1526. S = [-35] the iteration traversal
Douglas C. Schmidt
Visitor
The iterator controls the order in which accept() is called on each node in the composition accept() then visits the node to perform the desired evaluation action
Iterator Leaf_Node(5) Composite_Negate_Node eval_visitor
accept(eval_visitor)
stack_.push(node.item());
accept(eval_visitor)
stack_.push(-stack_.pop());
153
Douglas C. Schmidt
Visitor
Consequences
+ Flexibility: Visitor algorithm(s) & object structure are independent + Separation of concerns: Localized functionality in the visitor subclass instance Tight coupling: Circular dependency between Visitor & Element interfaces Visitor thus brittle to new ConcreteElement classes
154
Douglas C. Schmidt
Visitor
Consequences
+ Flexibility: Visitor algorithm(s) & object structure are independent + Separation of concerns: Localized functionality in the visitor subclass instance Tight coupling: Circular dependency between Visitor & Element interfaces Visitor thus brittle to new ConcreteElement classes Implementation Double dispatch General interface to elements of object structure
155
Douglas C. Schmidt
Visitor
Consequences
+ Flexibility: Visitor algorithm(s) & object structure are independent + Separation of concerns: Localized functionality in the visitor subclass instance Tight coupling: Circular dependency between Visitor & Element interfaces Visitor thus brittle to new ConcreteElement classes Implementation Double dispatch General interface to elements of object structure Known Uses ProgramNodeEnumerator in Smalltalk-80 compiler IRIS Inventor scene rendering TAO IDL compiler to handle different backends
156
Douglas C. Schmidt
Implementing STL Iterator Semantics

Goals Ensure the proper semantics of post-increment operations for STL-based ET_Iterator objects, i.e.: Expression_Tree value = iter++ vs. Expression_Tree value = ++iter
157
Douglas C. Schmidt

Goals Ensure the proper semantics of post-increment operations for STL-based ET_Iterator objects Expression_Tree value = iter++ vs. Expression_Tree value = ++iter Constraints/forces STL pre-increment operations are easy to implement since they simply increment the value & return *this, e.g., iterator &operator++() { ++...; return *this; }
158
Douglas C. Schmidt

Goals Ensure the proper semantics of post-increment operations for STL-based ET_Iterator objects Expression_Tree value = iter++ vs. Expression_Tree value = ++iter Constraints/forces STL pre-increment operations are easy to implement since they simply increment the value & return *this, e.g., iterator &operator++() { ++...; return *this; } STL post-increment operations are more complicated since they return a copy of the existing iterator before incrementing its value, e.g., iterator operator++(int) { iterator temp = copy_*this; ++...; return temp; }
159
Douglas C. Schmidt

Goals Ensure the proper semantics of post-increment operations for STL-based ET_Iterator objects Expression_Tree value = iter++ vs. Expression_Tree value = ++iter Constraints/forces STL pre-increment operations are easy to implement since they simply increment the value & return *this, e.g., iterator &operator++() { ++...; return *this; } STL post-increment operations are more complicated since they return a copy of the existing iterator before incrementing its value, e.g., iterator operator++(int) { iterator temp = copy_*this; ++...; return temp; } Since our ET_Iterator objects use the Bridge pattern it is tricky to implement the copy_*this step above in a generic way
160 to say ++iter than iter++ As a general rule, in STL its better
Douglas C. Schmidt
Solution: Clone a New Instance Via a Prototype

ET_Iterator operator++(int)
impl_
ET_Iterator_Impl clone()
In_Order_ET_Iterator_Impl clone() Level_Order_ET_Iterator_Impl clone() clone()
Post_Order_ET_Iterator_Impl clone() Pre_Order_ET_Iterator_Impl
iterator ET_Iterator::operator++(int) { iterator temp(impl_->clone()); ++(*impl_); return temp; }
The Bridge pattern abstraction class neednt have direct knowledge of implementor subclass details
Douglas C. Schmidt
ET_Iterator_Impl Class Interface

Subclasses of this base class define various iterations algorithms that can
traverse an expression tree Interface ET_Iterator_Impl (const Expression_Tree &tree) virtual Component_Node * operator *()=0 void operator++()=0 virtual bool operator==(const ET_Iterator_Impl &)=0 virtual bool operator!= (const ET_Iterator_Impl &)=0 virtual ET_Iterator_Impl * clone()=0
Subclass performs a deep copy
Commonality: Provides a common interface for expression tree iterator
implementations Variability: Each subclass implements the clone() method to return a deep copy of itself for use by ET_Iterator::operator++(int) 162
Douglas C. Schmidt
Prototype
Intent
Specify the kinds of objects to create using a prototypical instance & create new objects by copying this prototype Applicability
When the classes to instantiate are specified at run-time Theres a need to avoid the creation of a factory hierarchy It is more convenient to copy an existing instance than to create a new one
Structure
e.g., ET_Iterator_Impl
e.g., ET_Iterator e.g., Pre_Order_ET_Iterator_Impl, In_Order_ET_Iterator_Impl, etc.
163
Douglas C. Schmidt
Prototype
Prototype example in C++
Relationship between iterator interface (Bridge) & implementor hierarchy (Prototype)

iterator ET_Iterator::operator++(int) { iterator temp(impl_->clone()); ++(*impl_); The Bridge pattern abstraction class return temp; calls clone() on the implementor } subclass to get a deep copy without breaking encapsulation
164
Douglas C. Schmidt
Prototype
Prototype example in C++
Relationship between iterator interface (Bridge) & implementation (Prototype)

iterator ET_Iterator::operator++(int) { iterator temp(impl_->clone()); ++(*impl_); return temp; This method encapsulates the details } of making a deep copy of itself ET_Iterator_Impl *Pre_Order_ET_Iterator_Impl::clone() { return new Pre_Order_ET_Iterator_Impl(*this); } 165
Douglas C. Schmidt
Prototype
Consequences + Can add & remove classes at runtime by cloning them as needed + Reduced subclassing minimizes need for lexical dependencies at run-time
Every class that used as a prototype must itself be instantiated Classes that have circular references to other classes cannot really be cloned
166
Douglas C. Schmidt
Prototype
Every class that used as a prototype must itself be instantiated Classes that have circular references to other classes cannot really be cloned Implementation
Use prototype manager Shallow vs. deep copies Initializing clone internal state within a
uniform interface
167
Douglas C. Schmidt
Prototype

Known Uses
The first widely known
application of the Prototype pattern in an object-oriented language was in ThingLab related to the Prototype pattern for C++ & gives many examples & variations
Every class that used as a prototype must itself be instantiated Classes that have circular references to other classes cannot really be cloned Implementation
Jim Coplien describes idioms
Use prototype manager Shallow vs. deep copies Initializing clone internal state within a
uniform interface
168
Etgdb debugger for ET++ The music editor example is

based on the Unidraw drawing framework
Douglas C. Schmidt
Summary of Tree Traversal Patterns

The Iterator, Prototype, & Visitor patterns traverse the expression tree & perform designated operations
<< accept >>
Visitor
ET_Visitor
Expression_Tree
Component_Node
Iterator
<< create >> Evaluation_Visitor Print_Visitor
ET_Iterator
ET_Iterator_Impl
std::queue
Level_Order_Expression _Tree_Iterator_Impl In_Order_Expression _Tree_Iterator_Impl Post_Order_Expression _Tree_Iterator_Impl Pre_Order_Expression _Tree_Iterator_Impl std::stack
Prototype
169 These patterns allow adding new operations without affecting tree structure

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study ET_Command Evaluate the limitations with _Factory algorithmic design techniques Present an OO design for expression tree processing app Summarize the patterns in the expression tree design Explore patterns for Tree structure & access Tree creation Tree traversal Commands & factories
Print_ Command ET_Command the _Factory_Impl ET_Command
ET_Command_Impl
Format_ Command Macro_ Command
Expr_ Command
Eval_ Command
Quit_ Command
171
Douglas C. Schmidt
Overview of Command & Factory Patterns

P urpose: Define operations that can users can perform on an expression tree processing app & centralize extensible creation of these operations
ET_Event_Handler ET_Command_Factory ET_Command _Factory_Impl
Abstract Factory & Factory Method
<< create >>
Concrete_ET_ Command_Factory_Impl
ET_Context
ET_Command
ET_Command_Impl
Command
1 Macro_Command Print_Command Set_Command Quit_Command Null_Command
Format_Command
Expr_Command
Eval_Command
172 These patterns decouple creation from use & provide a uniform command API
Douglas C. Schmidt
Problem: Consolidating User Operations

Goals Support execution of user operations % tree-traversal -v format [in-order] Verbose mode expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit > format in-order > expr 1+4*3/2 > eval post-order 7 > quit % tree-traversal > 1+4*3/2 7
173
Douglas C. Schmidt

Goals Support execution of user operations Support macro operations % tree-traversal -v format [in-order] expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit > format in-order > expr 1+4*3/2 > eval post-order 7 > quit % tree-traversal > 1+4*3/2 7
174
Succinct mode
Douglas C. Schmidt

Goals Support execution of user operations Support macro operations Constraints/forces Avoid scattering the implementation of operations throughout the source code Ensure consistent memory management
175
Douglas C. Schmidt
Solution: Encapsulate an Operation w/Command

A Command encapsulates An operation method (execute()) An inverse operation method (unexecute()) A test for reversibility (boolean reversible()) State for (un)doing the operation
ET_Command_Impl ET_Command
Format_ Command Macro_ Command
Expr_ Command
Eval_ Command
Print_ Command
Quit_ Command
176
Douglas C. Schmidt
Solution: Encapsulate an Operation w/Command

A Command encapsulates An operation method (execute()) An inverse operation method (unexecute()) A test for reversibility (boolean reversible()) State for (un)doing the operation A Command may Implement the operation itself or Forward the operation implementation to other object(s)
Macro_ Command ET_Command_Impl ET_Command
Format_ Command
Expr_ Command
Eval_ Command
Print_ Command
Quit_ Command
Douglas C. Schmidt
ET_Command Class Interface

Interface for defining a command thatwhen executedperforms an
operation on an expression tree
This class plays the role of the abstraction in the Bridge pattern
Interface
ET_Command(ET_Command_Impl *=0) ET_Command(const ET_Command &) ET_Command & operator=(const ET_Command &) ~ET_Command() These methods forward to bool execute() the implementor subclass bool unexecute()
We dont use this method but its a common command feature
Commonality: Provides common interface for expression tree commands Variability: Implementations of expression tree commands can vary
depending on the operations requested by user input
178
Douglas C. Schmidt
ET_Command_Impl Class Interface

Base class of an implementor hierarchy used to define commands that
perform operations on an expression tree when they are executed
This class is the base class of the implementor hierarchy in the Bridge pattern
Interface
ET_Command_Impl(ET_Context &) ~ET_Command_Impl()= 0 ... The bulk of the work is virtual bool execute()=0 typically done here by virtual bool unexecute()=0
subclasses
Commonality: Provides a common base class for implementations of

expression tree commands
Variability: Subclasses of this base class implement different expression

tree commands depending on the operations requested by user input
179
Douglas C. Schmidt
Command
Intent Applicability
Encapsulate the request for a service as an object Want to parameterize objects with an action to perform Want to specify, queue, & execute requests at different times For multilevel undo/redo Structure
e.g., ET_Command_Impl
e.g., Eval_Command, Format_Command, Print_Command, Quit_Command, Macro_Command, etc.
180
Douglas C. Schmidt
Command
Command example in C++
Encapsulate execution of a sequence of commands as an object

class Macro_Command : public ET_Command_Impl { public: Executes a sequence of commands (used to ... implement succinct mode) bool execute() { std::for_each (macro_commands_.begin(), macro_commands_.end(), std::mem_fun_ref(&ET_Command::execute)); return true; } private: std::vector <ET_Command> macro_commands_; ... Vector of commands to execute as a macro 181
Douglas C. Schmidt
Command
Encapsulate execution of a sequence of commands as an object

class Macro_Command : public ET_Command_Impl { public: ... STL for_each() algorithm bool execute() { std::for_each (macro_commands_.begin(), macro_commands_.end(), std::mem_fun_ref(&ET_Command::execute)); return true; } Application of the Adapter pattern private: std::vector <ET_Command> macro_commands_; ... Vector of commands to execute as a macro 182
Douglas C. Schmidt
Command
Encapsulate execution of a sequence of subcommands as an object

class Macro_Command : public ET_Command_Impl { public: ... bool execute() { std::for_each (macro_commands_.begin(), macro_commands_.end(), [](ET_Command &c){ c.execute(); }); return true; } C++11 lambda expression private: std::vector <ET_Command> macro_commands_; ... 183
Douglas C. Schmidt
Command
Encapsulate execution of a sequence of subcommands as an object

class Macro_Command : public ET_Command_Impl { public: ... bool execute() { for (auto &iter = macro_commands_) iter.execute(); return true; } C++11 range-based for loop
private: std::vector <ET_Command> macro_commands_; ... 184
Douglas C. Schmidt
Command
Consequences + Abstracts executor of a service + Supports arbitrary-level undo-redo + Composition yields macro-commands Might result in lots of trivial command subclasses Excessive memory may be needed to support undo/redo operations
185
Douglas C. Schmidt
Command
Consequences + Abstracts executor of a service + Supports arbitrary-level undo-redo + Composition yields macro-commands Might result in lots of trivial command subclasses Excessive memory may be needed to support undo/redo operations Implementation
Copying a command before putting it on a history list Avoiding error accumulation during undo/redo Supporting transactions
186
Douglas C. Schmidt
Command
Consequences + Abstracts executor of a service + Supports arbitrary-level undo-redo + Composition yields macro-commands Might result in lots of trivial command subclasses Excessive memory may be needed to support undo/redo operations Implementation

Known Uses InterViews Actions MacApp, Unidraw Commands JDKs UndoableEdit, AccessibleAction Emacs Microsoft Office tools See Also Command Processor pattern in POSA1
Copying a command before putting it on a history list Avoiding error accumulation during undo/redo Supporting transactions
187
Douglas C. Schmidt
Problem: Consolidating Creation of Variabilities

Goals Simplify & centralize the creation of all variabilities in the expression tree application to ensure semantic compatibility Be extensible for future variabilities
ET_Command ET_Command_Impl
Format_Command
Print_Command
Eval_Command
Quit_Command
Expr_Command
Macro_Command
ET_Iterator
ET_Iterator_Impl
Post_Order_ET_Iterator_Impl
188
Pre_Order_ET_Iterator_Impl
Douglas C. Schmidt
Problem: Consolidating Creation of Variabilities

Goals Simplify & centralize the creation of all variabilities in the expression tree application to ensure semantic compatibility Be extensible for future variabilities
ET_Command ET_Command_Impl
Constraints/forces Dont recode existing clients Add new variabilities without recompiling
Format_Command
Print_Command
Eval_Command
Quit_Command
Expr_Command
Macro_Command
ET_Iterator
ET_Iterator_Impl
Post_Order_ET_Iterator_Impl
189
Pre_Order_ET_Iterator_Impl
Douglas C. Schmidt
Solution: Abstract Object Creation

Factory Instead of Use
Hard-codes a lexical dependency on
Print_Command ET_Command command(new Print_Command());

No lexical dependency on any concrete class
ET_Command command (command_factory.make_command("print")); where command_factory is an instance of ET_Command_Factory
190
Douglas C. Schmidt
Solution: Abstract Object Creation

Factory Instead of ET_Command command(new Print_Command()); Use ET_Command command (command_factory.make_command("print")); where command_factory is an instance of ET_Command_Factory Factory structure
ET_Command_Factory ET_Command_Factory_Impl Concrete_ET_Command _Factory_Impl 191& simplifies memory management Bridge pattern encapsulates variability
Douglas C. Schmidt
ET_Command_Factory Class Interface

Interface used to create appropriate command based on string supplied
by caller Interface
This class plays the role of the abstraction in the Bridge pattern
ET_Command_Factory(ET_Context &tree_context) ET_Command_Factory(ET_Command_Factory_Impl *) ET_Command make_command(const std::string &s) ...

These are helper factory methods This is the main factory method
ET_Command ET_Command ET_Command ET_Command ET_Command ET_Command
make_format_command(const std::string &) make_expr_command(const std::string &) make_print_command(const std::string &) make_eval_command(const std::string &) make_quit_command(const std::string &) make_macro_command(const std::string &)
Commonality: Provides a common interface to create commands Variability: Implementations of expression tree command factory
methods can vary depending on the requested commands 192
Douglas C. Schmidt
ET_Command_Factory_Impl Class Interface

Base class of an implementor hierarchy used to create appropriate commands
based on string supplied by caller Interface
This class is base class of implementor hierarchy in the Bridge pattern
ET_Command_Factory_Impl(ET_Context &context) ~ET_Command_Factory_Impl() virtual ET_Command make_command(const std::string &s)=0 ... Pure virtual methods virtual virtual virtual virtual virtual virtual ET_Command ET_Command ET_Command ET_Command ET_Command ET_Command make_format_command(const std::string &)=0 make_expr_command(const std::string &)=0 make_print_command(const std::string &)=0 make_eval_command(const std::string &)=0 make_quit_command(const std::string &)=0 make_macro_command(const std::string &)=0
Commonality: Provides a common interface to create commands Variability: Subclasses of this base class define expression tree
command factory methods vary depending on the requested commands 193
Douglas C. Schmidt
Factory Structure
ET_Command_Factory ET_Command
ET_Command_Factory_Impl
ET_Command_Impl
Concrete_ET_Command _Factory_Impl +make_command() #make_expr_command() #make_format_command() #make_eval_command() #make_macro_command() #make_quit_command() #make_print_command() Format_ Command Macro_ Command Print_ Command Expr_ Command Eval_ Command Quit_ Command
Each factory method creates a different type of concrete command
Douglas C. Schmidt
Factory Method
Intent concrete type to a subclass
GoF Class Creational
Provide an interface for creating an object, but leave choice of objects

Applicability
When a class cannot anticipate the objects it must create or a class

wants its subclasses to specify the objects it creates
e.g., ET_Command_Impl
Structure
e.g., ET_Command _Factory_Impl
e.g., Concrete_ET_ Command_Factory_Impl
e.g., Eval_Command, Print_ Command, Macro_Command, etc.
195
Douglas C. Schmidt
Factory Method
Factory Method example in C++
An interface for creating a command, letting subclass chose concrete type

class ET_Command_Factory_Impl { Pure virtual method public: virtual ET_Command make_macro_command(const std::string &) = 0; ...
196
Douglas C. Schmidt
Factory Method
Factory Method example in C++
An interface for creating a command, letting subclass chose concrete type

class ET_Command_Factory_Impl { public: virtual ET_Command make_macro_command(const std::string &) = 0; ... class Concrete_ET_Command_Factory_Impl Used to implement : public ET_Command_Factory_Impl { public: succinct mode virtual ET_Command make_macro_command(const std::string &expr) { std::vector <ET_Command> commands; Create vector of commands that are executed as a macro commands.push_back(make_format_command("in-order")); commands.push_back(make_expr_command(expr)); commands.push_back(make_eval_command("post-order")); return ET_Command(new Macro_Command(tree_context_, commands)); } 197 Encapsulates command within Bridge abstraction object
Douglas C. Schmidt
Factory Method
Consequences
+ Flexibility: The client becomes more flexible by not specifying the class name of the concrete class & the details of its creation + Decoupling: The client only depends on the interface More classes: Construction of objects requires an additional class in some cases
198
Douglas C. Schmidt
Factory Method
Consequences
+ Flexibility: The client becomes more flexible by not specifying the class name of the concrete class & the details of its creation + Decoupling: The client only depends on the interface More classes: Construction of objects requires an additional class in some cases Implementation There are two choices The creator class is abstract & does not implement creation methods (then it must be subclassed) The creator class is concrete & provides a default implementation (then it can be subclassed) If a factory method can create different variants the method should be passed a parameter to designate the variant 199
Douglas C. Schmidt
Factory Method
Consequences

Known Uses InterViews Kits ET++ WindowSystem AWT Toolkit The ACE ORB (TAO) BREW feature phone frameworks
+ Flexibility: The client becomes more flexible by not specifying the class name of the concrete class & the details of its creation + Decoupling: The client only depends on the interface More classes: Construction of objects requires an additional class in some cases Implementation There are two choices
The creator class is abstract & does not implement creation methods (then it must be subclassed) The creator class is concrete & provides a default implementation (then it can be subclassed) If a factory method can create different variants the method must be provided with a parameter 200
Douglas C. Schmidt
Abstract Factory
Create families of related objects without specifying subclass names When clients cannot anticipate groups of classes to instantiate
Structure
e.g., ET_Command _Impl e.g., ET_Command _Factory_Impl e.g., Eval_Command, Print_ Command, Macro_Command, etc.
e.g., Concrete_ET_ Command_Factory_Impl
201
Douglas C. Schmidt
Abstract Factory
Abstract Factory example in C++
Create families of related objects without specifying subclass names

class Concrete_ET_Command_Factory_Impl : public ET_Command_Factory_Impl { public: Concrete_ET_Command_Factory_Impl() { command_map_["format"] = &make_format_command; command_map_["expr"] = &make_expr_command; command_map_["eval"] = &make_eval_command; ... std::map associating command names to pointerto-member-function command factories
202
Douglas C. Schmidt
Abstract Factory
Abstract Factory example in C++
Create families of related objects without specifying subclass names

class Concrete_ET_Command_Factory_Impl : public ET_Command_Factory_Impl { public: Concrete_ET_Command_Factory_Impl() { command_map_["format"] = &make_format_command; command_map_["expr"] = &make_expr_command; command_map_["eval"] = &make_eval_command; ... The primary factory method that creates the
designated command based on user input virtual ET_Command make_command(const std::string &input) { auto iter = command_map_.find(command_name(input)); if (iter != command_map_.end()) { auto ptmf = iter->second; return (this->*ptmf)(command_parameter(input)); } Dispatch command 203factory method via returned via map ...
Douglas C. Schmidt
Abstract Factory
Consequences + Flexibility: Removes type (i.e., subclass) dependencies from clients + Abstraction & semantic checking: Encapsulates products composition Complexity: Tedious to extend factory interface to create new products
204
Douglas C. Schmidt
Abstract Factory
Consequences + Flexibility: Removes type (i.e., subclass) dependencies from clients + Abstraction & semantic checking: Encapsulates products composition Complexity: Tedious to extend factory interface to create new products Implementation Parameterization as a way of controlling interface size
Configuration with prototypes to determine who creates the factories Abstract factories are essentially groups of factory methods
205
Douglas C. Schmidt
Abstract Factory
Consequences + Flexibility: Removes type (i.e., subclass) dependencies from clients + Abstraction & semantic checking: Encapsulates products composition Complexity: Tedious to extend factory interface to create new products Implementation Parameterization as a way of controlling interface size

Known Uses InterViews Kits ET++ WindowSystem AWT Toolkit The ACE ORB (TAO)
Configuration with prototypes to determine who creates the factories Abstract factories are essentially groups of factory methods
206
Douglas C. Schmidt
Summary of Command & Factory Patterns

which then dictate how users interact with an expression tree processing app
ET_Event_Handler ET_Command_Factory ET_Command_Factory_Impl
Abstract Factory contains Factory Methods that create Command objects,
Abstract Factory & Factory Method
<< create >>
Concrete_ET_Command_Factory_Impl
ET_Context
ET_Command
ET_Command_Impl
Command
1 Macro_Command Print_Command Set_Command Quit_Command Null_Command
Format_Command
Expr_Command
Eval_Command
207 These patterns enable extensibility of operations via new factory methods

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques Present an OO design for the expression tree processing app Summarize the patterns in the expression tree design Explore patterns for Tree structure & access Tree creation Tree traversal Commands & factories Command ordering protocols
209 quit() print() make_tree() eval() format() make_tree() *_Order_ Uninitialized State format() Uninitialized State
*_Order_ Initialized State
Douglas C. Schmidt
Overview of a Command Protocol Pattern

P urpose: Ensure user commands are performed in the correct order
ET_Context
ET_State
Uninitialized _State
Pre_Order_ Uninitialized_State
Post_Order_ Uninitialized_State
In_Order_ Uninitialized_State
Level_Order_ Uninitialized_State
Pre_Order_ Initialized_State
Post_Order_ Initialized_State
In_Order_ Initialized_State
Level_Order_ Initialized_State
State
<< use >> ET_Interpreter
This pattern uses design of classes to 210 explicitly order user commands correctly
Douglas C. Schmidt
Problem: Ensuring Correct Command Protocol

Goals Ensure that users follow the correct protocol when entering commands % tree-traversal -v format [in-order] expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit Protocol > format in-order violation > print in-order Error: ET_State::print called in invalid state
211
Douglas C. Schmidt
Problem: Ensuring Correct Command Protocol

Goals Ensure that users follow the correct protocol when entering commands Constraints/forces Must consider context of previous commands to determine protocol conformance, e.g., format must be called first expr must be called before print or eval % tree-traversal -v format [in-order] expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit Protocol > format in-order violation > print in-order Error: ET_State::print called in invalid state
print & eval can be

called in any order
212
Douglas C. Schmidt
Solution: Encapsulate Command History as States

Handling user commands depends on history of prior commands This Uninitialized history can be State represented as a state machine
Uninitialized State format()
*_Order_ Uninitialized State format()
make_tree() *_Order_ Initialized State
print() quit() make_tree() eval()
213
Douglas C. Schmidt

214
Douglas C. Schmidt

215
Douglas C. Schmidt

216
Douglas C. Schmidt

217
Douglas C. Schmidt

218
Douglas C. Schmidt

Handling user commands depends on history of prior commands
*_Order_ Uninitialized State make_tree() format() *_Order_ Initialized State eval() make_tree() print()
This Uninitialized history can be State represented as a format() state machine The state machine can be encoded using various subclasses that enforce the correct protocol for user commands
quit()
219 & simplifies memory management ET_Context also encapsulates variability
Douglas C. Schmidt
ET_Context Class Interface

Interface used to ensure commands are invoked according to correct protocol
These methods correspond to user commands
Interface
void void void void
ET_State * void Expression_Tree & void
format(const std::string &new_format) make_tree(const std::string &expression) print(const std::string &format) evaluate(const std::string &format) ... Setter/getter for state() const ET_State subclasses state(ET_State *new_state) tree() tree(const Expression_Tree &new_tree)
Commonality: Provides a common interface for ensuring that
expression tree commands are invoked according to the correct protocol
Variability: The implementations& correct functioningof the

expression tree commands can vary depending on the requested operations & the current state 220
Douglas C. Schmidt
ET_State Class Interface

Implementation used to define the various states that affect how users
commands are processed Interface virtual void format(ET_Context &context, const std::string &new_format) virtual void make_tree(ET_Context &context, const std::string &expression) virtual void print(ET_Context &context, const std::string &format) virtual void evaluate(ET_Context &context, const std::string &format)
These methods are delegated from ET_Context methods
Commonality: Provides a common interface for ensuring that
expression tree commands are invoked according to the correct protocol
Variability: The implementations& correct functioningof the

expression tree commands can vary depending on the requested operations & the current state 221
Douglas C. Schmidt
State
Intent
Allow an object to alter its behavior when its internal state changesthe object will appear to change its class Applicability
When an object must change its behavior at run-time depending on

which state it is in
When several operations have the same large multipart conditional

structure that depends on the object's state
e.g., ET_State
Structure
e.g., Uninitialized_State, Pre_Order_Uninitialized_State, Pre_Order_Initialized_State, etc.
e.g., ET_Context
222
Douglas C. Schmidt
State
State example in C++

This method delegates to the ET_State object
Allows ET_Context object to alter its behavior when its state changes
void ET_Context::make_tree(const std::string &expression) { state_->make_tree(*this, expression); }
class Uninitialized_State { public: virtual void make_tree(ET_Context &tc, const std::string &expr) { throw Invalid_State("make_tree called in invalid state"); } ...
Its invalid to call make_tree() in this state
223
Douglas C. Schmidt
State
State example in C++

This method delegates to the ET_State object
Allows ET_Context object to alter its behavior when its state changes
void ET_Context::make_tree(const std::string &expression) { state_->make_tree(*this, expression); }
class In_Order_Uninitialized_State : public Uninitialized_State { public: Calling make_tree() in this state initializes expression tree virtual void make_tree(ET_Context &et_context, const std::string &expr) { ET_Interpreter interp; ET_Interpreter_Context interp_context; et_context.tree(interp.interpret (interp_context, expr)); et_context.state(new In_Order_Initialized_State); } ... Transition to the new state 224
Douglas C. Schmidt
State
Consequences + It localizes state-specific behavior & partitions behavior for different states + It makes state transitions explicit + State objects can be shared Can result in lots of subclasses that are hard to understand
225
Douglas C. Schmidt
State
Consequences + It localizes state-specific behavior & partitions behavior for different states + It makes state transitions explicit + State objects can be shared Can result in lots of subclasses that are hard to understand Implementation Who defines state transitions? Consider using table-based alternatives Creating & destroying state objects
226
Douglas C. Schmidt
State
Consequences + It localizes state-specific behavior & partitions behavior for different states + It makes state transitions explicit + State objects can be shared Can result in lots of subclasses that are hard to understand Implementation Who defines state transitions? Consider using table-based alternatives Creating & destroying state objects

Known Uses
The State pattern & its
application to TCP connection protocols are characterized by Ralph Johnson & Johnny Zweig in their article Delegation in C++. Journal of Object-Oriented Programming, 4(11):22-35, November 1991
Unidraw & Hotdraw drawing

tools
227
Douglas C. Schmidt
Summary of State Pattern

State ensures user commands are performed in the correct order
ET_Context
ET_State
Uninitialized _State
Pre_Order_ Uninitialized_State
Post_Order_ Uninitialized_State
In_Order_ Uninitialized_State
Level_Order_ Uninitialized_State
Pre_Order_ Initialized_State
Post_Order_ Initialized_State
In_Order_ Initialized_State
Level_Order_ Initialized_State
State
<< use >> ET_Interpreter
This pattern uses design of classes to 228 explicitly order user commands correctly

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques Present an OO design for the expression tree processing app Summarize the patterns in the expression tree design Explore patterns for Tree structure & access Tree creation Tree traversal Commands & factories Command ordering protocols Application structure
230
Verbose_ET_ Event_Handler Succinct_ET_ Event_Handler Reactor register_handler() remove_handler() run_event_loop() end_event_loop() Event_Handler
ET_Event_Handler
Douglas C. Schmidt
Overview of Application Structure Patterns

P urpose: Structure the overall control flow of the event-driven expression tree processing app
Reactor
Reactor Event_Handler
Singleton
Options
ET_Command_Factory
ET_Event_Handler
ET_Context
<< create >>
ET_Command
231 of events & user options These patterns simplify processing
Douglas C. Schmidt
Problem: Structuring Application Event Flow

Goals
Decouple expression tree

processing app from the context in which it runs
e.g., command-line vs.
various GUI environments
% tree-traversal -v format [in-order] expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit > format in-order > expr 1+4*3/2 > eval post-order 7 > quit
232
Douglas C. Schmidt
Problem: Structuring Application Event Flow

Goals
Decouple expression tree

processing app from the context in which it runs
e.g., command-line vs.

Constraints/forces
various GUI environments
Dont hard-code control flow into app logic Dont hard-code event processing logic into app structure
233
Douglas C. Schmidt
Solution: Separate Event Handling Concerns

Create a reactor to detect input on various
sources of events
Reactor register_handler() remove_handler() run_event_loop() end_event_loop()
234
Douglas C. Schmidt

Reactor register_handler() remove_handler() run_event_loop() end_event_loop() Event_Handler
sources of events & then demux & dispatch the events to the appropriate event handlers
ET_Event_Handler
Verbose_ET_ Event_Handler Succinct_ET_ Event_Handler
235
Douglas C. Schmidt

sources of events & then demux & dispatch the events to the appropriate event handlers handlers & register the concrete event handlers with the reactor
Event handlers perform various operation modes of the expression tree processing app
Create concrete event
236
Douglas C. Schmidt

sources of events & then demux & dispatch the events to the appropriate event handlers handlers & register the concrete event handlers with the reactor loop to drive the application event flow
Note the inversion of control
Create concrete event
Run the reactors event
237
Douglas C. Schmidt
Reactor & Event Handler Class Interfaces

An object-oriented event demultiplexor & dispatcher of event handler
callback methods in response to various types of events
Enact inversion of control
Interface
void void void void static Reactor * instance()
~Reactor() run_event_loop() end_event_loop() register_handler(Event_Handler *event_handler) remove_handler(Event_Handler *event_handler)

Singleton access point Attach/detact event handlers
238
Douglas C. Schmidt
Reactor & Event Handler Class Interfaces

An object-oriented event demultiplexor & dispatcher of event handler
hook methods in response to various types of events
<<uses>>
Interface
void void void void static Reactor * instance()
~Reactor() run_event_loop() Process an event end_event_loop() register_handler(Event_Handler *event_handler) remove_handler(Event_Handler *event_handler)
virtual void ~Event_Handler()=0 virtual void delete_this() virtual void handle_input()=0
Commonality: Provides a common interface for managing & processing

events via callbacks to abstract event handlers
Variability: Concrete implementations of Reactor & event handlers can

be tailored to a wide range of OS muxing mechanisms & applicationspecific concrete event handling behaviors 239
Douglas C. Schmidt
Reactor
Intent
POSA2 Architectural Pattern
Allows event-driven applications to demultiplex & dispatch service requests

that are delivered to an application from one or more clients Applicability
Need to decouple event handling from event management infrastructure When multiple sources of events must be handled in a single thread
Structure
e.g., Event_Handler
e.g., Verbose_ET _Event_Handler, Succinct_ET_ Event_Handler
240 See www.dre.vanderbilt.edu/~schmidt/PDF/Reactor.pdf for the Reactor pattern
Douglas C. Schmidt
Reactor
Reactor example in C++
Detect/demux events & dispatch event handler callback methods in response

class Reactor { Singleton access point public: static Reactor *instance(); void run_event_loop() { Run the app event loop while (run_event_loop_) wait_for_next_event()->handle_input(); } void register_input_handler(Event_Handler *event_handler) { dispatch_table_.push_back(eh); } ... Register an event handler for
input events in dispatch table private: std::vector <Event_Handler *> dispatch_table_; ... 241
Douglas C. Schmidt
Reactor
Consequences + Simplify concurrency control Non-preemptive Scalability issues
+ Separation of concerns & portability
242
Douglas C. Schmidt
Reactor
Consequences + Simplify concurrency control Non-preemptive Scalability issues Implementation
Decouple event detection/demuxing mechanisms from event dispatching e.g., via Bridge Handle many different types of events e.g., input/output events, signals, timers, etc.
243
Douglas C. Schmidt
Reactor
Consequences + Simplify concurrency control Non-preemptive Scalability issues Implementation

Known Uses X Windows Xt InterViews Dispatcher ET++ WindowSystem AWT Toolkit ACE & The ACE ORB (TAO) Java NIO package
Decouple event detection/demuxing mechanisms from event dispatching e.g., via Bridge Handle many different types of events e.g., input/output events, signals, timers, etc.
244 See gee.cs.oswego.edu/dl/cpjslides/nio.pdf for Java Reactor info
Douglas C. Schmidt
Problem: Managing Access to Global Resources

Goals Centralize access to resources that should be visible globally, e.g.: Command-line options that parameterize the program behavior Reactor that drives the main event loop % tree-traversal -v format [in-order] Verbose mode expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit > format in-order > expr 1+4*3/2 > eval post-order 7 > quit % tree-traversal > 1+4*3/2 7
245
Succinct mode
Douglas C. Schmidt
Problem: Managing Access to Global Resources

Goals Centralize access to resources that should be visible globally, e.g.: Command-line options that parameterize the program behavior Reactor that drives the main event loop Constraints/forces Only need one instance of command-line options & event loop driver Global variables are problematic in C++ % tree-traversal -v format [in-order] Verbose mode expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit > format in-order > expr 1+4*3/2 > eval post-order 7 > quit % tree-traversal > 1+4*3/2 7
246
Succinct mode
Douglas C. Schmidt
Solution: Centralize Access to Global Resources

Rather than using global variables, create a central access point to global
instances, e.g.:
int main(int argc, char *argv[]) { Parse the command-line options if(!Options::instance()->parse_args(argc, argv)) return 0; Dynamically allocate the appropriate event handler based on the ET_Event_Handler *event_handler = command-line options ET_Event_Handler::make_handler (Options::instance()->verbose()); Reactor::instance()->register_input_handler (event_handler); Register event handler with the event loop driver // ... 247
Douglas C. Schmidt
Singleton
Ensure a class only has one instance & provide a global point of access When there must be exactly one instance of a class & it must be accessible from a well-known access point When the sole instance should be extensible by subclassing & clients should be able to use an extended instance without modifying their code Structure
If (uniqueInstance == 0) uniqueInstance = new Singleton; return uniqueInstance;
e.g., Options & Reactor
248
Douglas C. Schmidt
Singleton
Singleton example in C++
Define a singleton class to handle command-line option processing

class Options { public: static Options *instance(); if (instance_ == 0) instance_ = new Options; return instance_;
// Parse command-line arguments and sets values as follows: // 't' - Traversal strategy, i.e., 'P' for pre-order, 'O' for // post-order, 'I' for in-order, & 'L' for level-order. bool parse_args(int argc, char *argv[]); bool verbose() const; // True if program runs in verbose mode. char traversal_strategy() // Returns desired traversal strategy. ... Accessor methods to check for enabled options private: Make constructor private to prevent multiple instances Options(); static Options *instance_; ... 249 Points to the one & only instance
Douglas C. Schmidt
Singleton
Consequences + Reduces namespace pollution + Makes it easy to change your mind & allow more than one instance + Allow extension by subclassing Same drawbacks of a global if misused Implementation may be less efficient than a global Concurrency/cache pitfalls & communication overhead
250for discussion of Singleton issues See c2.com/cgi/wiki?SingletonsAreEvil
Douglas C. Schmidt
Singleton
Consequences + Reduces namespace pollution + Makes it easy to change your mind & allow more than one instance + Allow extension by subclassing Same drawbacks of a global if misused Implementation may be less efficient than a global Concurrency/cache pitfalls & communication overhead Implementation Static instance operation
Registering singleton instance with manager Deleting singletons

251 www.research.ibm.com/designpatterns/pubs/ph-jun96.txt: Singleton deletion
Douglas C. Schmidt
Singleton

252 www.dre.vanderbilt.edu/~schmidt/PDF/ObjMan.pdf: Singleton management
Douglas C. Schmidt
Singleton

Known Uses Unidraw's Unidraw object Smalltalk-80 ChangeSet, the set of changes to code InterViews Session object ACE Singleton See Also Double-Checked Locking Optimization pattern from POSA2 book

253 en.wikipedia.org/wiki/Double-checked_locking has more synchronization info
Douglas C. Schmidt
Summary of Application Structure Patterns

Reactor structures the overall control flow of the event-driven expression tree processing app & Singleton simplifies access to global resources
Reactor
Reactor Event_Handler
Singleton
Options
ET_Command_Factory
ET_Event_Handler
ET_Context
<< create >>
ET_Command
254 The Reactor pattern embodies key characteristics of frameworks

Douglas C. Schmidt
Douglas C. Schmidt

Describe the object-oriented (OO) expression tree case study Evaluate the limitations with algorithmic design techniques Present an OO design for the expression tree processing app Summarize the patterns in the expression tree design Explore patterns for Tree structure & access Tree creation Tree traversal Commands & factories Command ordering protocols Application structure Encapsulating algorithm variability 256
Verbose_ET_ Event_Handler Succinct_ET_ Event_Handler Reactor register_handler() remove_handler() run_event_loop() end_event_loop() Event_Handler
ET_Event_Handler
Douglas C. Schmidt
Overview of Algorithm Variability Encapsulation Patterns

P urpose: Simplify processing of multiple operation modes
Reactor Event_Handler Options
ET_Command_Factory
ET_Event_Handler
ET_Context
<< create >>
ET_Command
These patterns support controlled257 variability of steps in an algorithm
Douglas C. Schmidt
Problem: Supporting Multiple Operation Modes

Goals
Minimize effort required to

support multiple modes of operation modes
e.g., verbose & succinct
% tree-traversal -v format [in-order] Verbose mode expr [expression] print [in-order|pre-order|postorder|level-order] eval [post-order] quit > format in-order > expr 1+4*3/2 > eval post-order 7 > quit % tree-traversal > 1+4*3/2 7
258
Succinct mode
Douglas C. Schmidt
Problem: Supporting Multiple Operation Modes

Goals
Minimize effort required to

support multiple modes of operation mode
e.g., verbose & succinct

Constraints/forces
Dont tightly couple the

operation modes with the program structure enhancements algorithmic decomposition
259
Simplify future
Avoid limitations of
Douglas C. Schmidt
Solution A: Encapsulate Algorithm Variability

Implement algorithm once in base class & let subclasses define variant parts
Event_Handler void handle_input() { prompt_user(); std::string input; if(!get_input(input)) Reactor::instance()->end_event_loop(); ET_Command command = make_command(input); if(!execute_command(command)) Reactor::instance()->end_event_loop(); }
260
Douglas C. Schmidt

The other four methods are hook methods
handle_input() is a template method
261
Douglas C. Schmidt

262
Douglas C. Schmidt

ET_Command make_command (const std::string &input) { return command_factory_. make_macro_command(input); }
ET_Command make_command (const std::string &input) { return command_factory_.make_command(input); }
263
Customized hook methods
Douglas C. Schmidt
ET_Event_Handler Class Interface

Provides an abstract interface for performing the algorithm associated
with the expression tree processing app Interface virtual void static ET_Event_Handler * virtual void virtual bool virtual ET_Command
Hook methods Template method Factory
handle_input() make_handler(bool verbose) prompt_user()=0 get_input(std::string &) make_command(const std::string &input)=0 virtual bool execute_command(ET_Command &)
Commonality: Provides a common interface for handling user input Variability: Subclasses implement various operation modes, e.g.,
verbose vs. succinct mode
events & performing steps in the expression tree processing algorithm
264
Douglas C. Schmidt
Template Method
Intent
Provide a skeleton of an algorithm in a method, deferring some steps to subclasses Applicability Implement invariant aspects of an algorithm once & let subclasses define variant parts Localize common behavior in a class to increase code reuse Control subclass extensions Structure
e.g., ET_Event_Handler e.g., Verbose_ET_Event _Handler, Succinct_ ET_Event_Handler
265
Douglas C. Schmidt
Template Method
Template Method example in C++
Allow subclasses to customize certain steps in event handling algorithm

void ET_Event_Handler::handle_input() { Template method prompt_user(); std::string input; if (!get_input(input)) Reactor::instance()->end_event_loop(); ET_Command command = make_command(input); if (!execute_command(command)) Reactor::instance()->end_event_loop(); ... Hook methods
266
Douglas C. Schmidt
Template Method

void ET_Event_Handler::handle_input() { prompt_user(); std::string input; if (!get_input(input)) Reactor::instance()->end_event_loop(); ET_Command command = make_command(input); if (!execute_command(command)) Reactor::instance()->end_event_loop(); ... ET_Command Verbose_ET_Event_Handler::make_command (const std::string &input) { return command_factory_.make_command(input); Specialized hook } methods ET_Command Succinct_ET_Event_Handler::make_command (const std::string &input) { return command_factory_.make_macro_command(input); 267 }
Douglas C. Schmidt
Template Method

void ET_Event_Handler::handle_input() { prompt_user(); std::string input; if (!get_input(input)) Reactor::instance()->end_event_loop(); ET_Command command = make_command(input); if (!execute_command(command)) Reactor::instance()->end_event_loop(); ... ET_Event_Handler *ET_Event_Handler::make_handler(bool verbose) { return verbose ? new Verbose_ET_Event_Handler : new Succint_ET_Event_Handler } Factory creates appropriate strategy objects 268 This is not the only (or best) way of defining a factory
Douglas C. Schmidt
Template Method
Consequences + Enables inversion of control (Hollywood principle: don't call us we'll call you!) + Promotes code reuse + Lets you enforce overriding rules Must subclass to specialize behavior (cf. Strategy pattern)
269
Douglas C. Schmidt
Template Method
Consequences + Enables inversion of control (Hollywood principle: don't call us we'll call you!) + Promotes code reuse + Lets you enforce overriding rules Must subclass to specialize behavior (cf. Strategy pattern) Implementation Virtual vs. non-virtual template method Few vs. many primitive operations (hook methods)
Naming conventions (do_*() vs. make_*() prefix)

270
Douglas C. Schmidt
Template Method
Consequences + Enables inversion of control (Hollywood principle: don't call us we'll call you!) + Promotes code reuse + Lets you enforce overriding rules Must subclass to specialize behavior (cf. Strategy pattern) Implementation Virtual vs. non-virtual template method Few vs. many primitive operations (hook methods)

Known Uses
InterViews Kits ET++ WindowSystem AWT Toolkit ACE & The ACE ORB (TAO) Android Activities
Naming conventions (do_*() vs. make_*() prefix)

271
Douglas C. Schmidt
Solution B: Encapsulate Algorithm Variability

Implement algorithm once in base class & let strategies define variant parts
Event_Handler void handle_input() { prompt_user(); ET_Event_Handler handle_input() std::string input; if(!get_input(input)) Reactor::instance() ->end_event_loop(); ET_Command cmd = make_command(input);
Same template method & hook methods as before
if(!execute_command(cmd)) Reactor::instance() ->end_event_loop(); }
272
Douglas C. Schmidt

Event_Handler
PROMPT_USER _STRATEGY GET_INPUT _STRATEGY
void handle_input() { prompt_user(); ET_Event_Handler handle_input()

PROMPT_USER_STRATEGY, GET_INPUT_STRATEGY, MAKE_COMMAND_STRATEGY, EXECUTE_COMMAND_STRATEGY
std::string input; if(!get_input(input)) Reactor::instance() ->end_event_loop(); ET_Command cmd = make_command(input); if(!execute_command(cmd)) Reactor::instance() ->end_event_loop(); }
MAKE_ COMMAND _STRATEGY
Strategy_ET_ Event_Handler
EXECUTE_ COMMAND _STRATEGY
handle_input() prompt_user() get_input() make_command() execute_command()
Strategy objects can be passed as arguments to Strategy_ET_Event_Handler constructor
Strategy objects can be defined 273 using C++ parameterized types
Douglas C. Schmidt

Event_Handler
PROMPT_USER _STRATEGY GET_INPUT _STRATEGY
void handle_input() { prompt_user(); ET_Event_Handler handle_input()

PROMPT_USER_STRATEGY, GET_INPUT_STRATEGY, MAKE_COMMAND_STRATEGY, EXECUTE_COMMAND_STRATEGY
std::string input; if(!get_input(input)) Reactor::instance() ->end_event_loop(); ET_Command cmd = make_command(input); if(!execute_command(cmd)) Reactor::instance() ->end_event_loop(); }
MAKE_ COMMAND _STRATEGY
Strategy_ET_ Event_Handler
EXECUTE_ COMMAND _STRATEGY
handle_input() prompt_user() get_input() make_command() execute_command()
Hook methods forward to strategy object methods
ET_Command make_command(const std::string &input) { return mc_strategy_.make_command(input); } bool execute_command(const std::string &input) { return ec_strategy_.execute_command(input); }
274
Douglas C. Schmidt
Strategy Template Parameters

Provides template parameters that perform steps in the algorithm associated
with the expression tree processing app Template Parameters MAKE_COMMAND _STRATEGY ET_Command make_command(const std::string &input) EXECUTE_COMMAND Expected method signatures _STRATEGY bool execute_command(const std::string &input) ...
Commonality: Provides common expected method signatures for
performing steps in the expression tree processing algorithm Variability: Template arguments provided to Strategy_ET_Event _Handler implement various operation modes, e.g., verbose vs. succinct
275
Douglas C. Schmidt
Strategy
Intent Define a family of algorithms, encapsulate each one, & make them interchangeable to let clients & algorithms vary independently Applicability When an object should be configurable with one of many algorithms, and all algorithms can be encapsulated, and one interface covers all encapsulations Structure
e.g., MAKE_COMMAND_ STRATEGY, EXECUTE_ COMMAND_STRATEGY, etc.
276
Douglas C. Schmidt
Strategy
Strategy example in C++
Customize algorithm behavior by composition/forwarding vs. inheritance

Parameterized template <..., typename MAKE_COMMAND_STRATEGY, type strategies typename EXECUTE_COMMAND_STRATEGY> class Strategy_ET_Event_Handler : public ET_Event_Handler { public: Reuse handle_input() Strategy_ET_Event_Handler template method (..., const MAKE_COMMAND_STRATEGY &mc_strategy, const EXECUTE_COMMAND_STRATEGY &ec_strategy) ... Pass strategy objects via constructor & assign to corresponding data members
277 Note combination of Template Method & Strategy patterns
Douglas C. Schmidt
Strategy

template <..., typename MAKE_COMMAND_STRATEGY, typename EXECUTE_COMMAND_STRATEGY> class Strategy_ET_Event_Handler : public ET_Event_Handler { public: Strategy_ET_Event_Handler (..., const MAKE_COMMAND_STRATEGY &mc_strategy, const EXECUTE_COMMAND_STRATEGY &ec_strategy) ... ... ET_Command make_command(const std::string &user_input) { return mc_strategy_.make_command(user_input); } Hook methods forward to strategy objects bool execute_command(ET_Command &command) { return ec_strategy_.execute_command(command); } 278
Douglas C. Schmidt
Strategy

template <..., typename MAKE_COMMAND_STRATEGY, typename EXECUTE_COMMAND_STRATEGY> class Strategy_ET_Event_Handler : public ET_Event_Handler { public: Strategy_ET_Event_Handler (..., const MAKE_COMMAND_STRATEGY &mc_strategy, const EXECUTE_COMMAND_STRATEGY &ec_strategy) ... ... Will be used as argument to the class Macro_Command_Strategy { Strategy_ET_Event_Handler public: parameterized type ... ET_Command make_command(const std::string &input) { return command_factory_.make_macro_command(input); } }; Creates a macro command 279
Douglas C. Schmidt
Strategy

template <..., typename MAKE_COMMAND_STRATEGY, typename EXECUTE_COMMAND_STRATEGY> class Strategy_ET_Event_Handler : public ET_Event_Handler { public: Strategy_ET_Event_Handler (..., const MAKE_COMMAND_STRATEGY &mc_strategy, const EXECUTE_COMMAND_STRATEGY &ec_strategy) ... ... Factory creates appropriate strategy objects ET_Event_Handler *Strategy_ET_Event_Handler::make_handler (bool verbose) { return verbose ? new Strategy_ET_Event_Handler <..., Command_Strategy, ...> : new Strategy_ET_Event_Handler <..., Macro_Command_Strategy, ...> } 280
Douglas C. Schmidt
Strategy
Consequences + Greater flexibility, reuse + Can change algorithms dynamically Strategy creation & communication overhead Inflexible Strategy interface Semantic incompatibility of multiple strategies used together
281
Douglas C. Schmidt
Strategy
Consequences + Greater flexibility, reuse + Can change algorithms dynamically Strategy creation & communication overhead Inflexible strategy interface Semantic incompatibility of multiple strategies used together Implementation Exchanging information between a strategy & its context Context is not always necessary Static binding of strategy selection via parameterized types
282
Douglas C. Schmidt
Strategy
Consequences + Greater flexibility, reuse + Can change algorithms dynamically Strategy creation & communication overhead Inflexible strategy interface Semantic incompatibility of multiple strategies used together Implementation Exchanging information between a strategy & its context Context is not always necessary Static binding of strategy selection via parameterized types

Known Uses InterViews text formatting RTL register allocation & scheduling strategies ET++SwapsManager calculation engines The ACE ORB (TAO) real-time object request broker middleware See Also Bridge pattern (object structural)
283
Douglas C. Schmidt
Comparing Strategy with Template Method

Strategy + Provides for clean separation between components via black-box interfaces + Allows for strategy composition at runtime + Supports flexible mixing & matching of features Incurs the overhead of forwarding May yield many strategy classes
284
Douglas C. Schmidt
Comparing Strategy with Template Method

Strategy + Provides for clean separation between components via black-box interfaces + Allows for strategy composition at runtime + Supports flexible mixing & matching of features Incurs the overhead of forwarding May yield many strategy classes Template Method + No explicit forwarding necessary + May be easier for small use cases Close coupling between subclass(es) & base class Inheritance hierarchies are static & cannot be reconfigured at runtime Adding features via inheritance may yield combinatorial subclass explosion Beware overusing inheritance since its not always the best choice Deep inheritance hierarchies in an app are a red flag
Strategy is commonly used for Black-box frameworks Template Method is commonly used for White-box frameworks
285
Douglas C. Schmidt
Overview of Algorithm Variability Encapsulation Patterns

The Strategy & Template Method patterns simplify processing of multiple operation modes
Reactor
Event_Handler
Options
ET_Command_Factory
ET_Event_Handler
ET_Context
<< create >>
Verbose_Expression_ Tree_Event_Handler
Macro_Expression_ Tree_Event_Handler
ET_Command
286 These patterns avoid limitations of algorithmic decomposition
Douglas C. Schmidt
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvements over the original algorithmic decomposition
Expression_Tree
Component_Node
Leaf_Node
1 Tree Node 0|1|2 287
Douglas C. Schmidt
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvements over the original algorithmic decomposition Much more modular & extensible
Expression_Tree
Component_Node
Leaf_Node
1 Tree Node 0|1|2 288
Douglas C. Schmidt
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvements over the original algorithmic decomposition Much more modular & extensible Design matches the domain better
Expression_Tree
Component_Node
Leaf_Node
1 Tree Node 0|1|2 289
Douglas C. Schmidt
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvements over the original algorithmic decomposition Much more modular & extensible Design matches the domain better Less space overhead
1 Tree Node 0|1|2 290 Koenigs Ruminations on C++ book has another OO expression tree example
Expression_Tree
Component_Node
Leaf_Node
Douglas C. Schmidt Visitor
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvement over the original algorithmic decomposition Exhibits high pattern density
Iterator
Prototype
291
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvement over the original algorithmic decomposition Exhibits high pattern density Nearly all classes & objects in design play a role in one or more patterns
Prototype Iterator
292
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvement over the original algorithmic decomposition Exhibits high pattern density Nearly all classes & objects in design play a role in one or more patterns Patterns help clarify the relationships of myriad classes in the design
Prototype Iterator
293
Douglas C. Schmidt
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvement over the original algorithmic decomposition Exhibits high pattern density Same design can easily be realized in common OO programming languages
Expression_Tree expr_tree = ...; Print_Visitor print_visitor; C++11 range-based for loop for (auto &iter : expr_tree) iter.accept(print_visitor);
ExpressionTree exprTree = ...; ETVisitor printVisitor = new PrintVisitor(); Java for-each loop for (ComponentNode node : exprTree) node.accept(printVisitor);
294
Douglas C. Schmidt
Summary
Pattern-oriented expression tree processing app design has many benefits: Major improvement over the original algorithmic decomposition Exhibits high pattern density Same design can easily be realized in common OO programming languages C++ & Java solutions are nearly identical, modulo minor syntactical & semantic differences
Expression_Tree expr_tree = ...; Print_Visitor print_visitor; C++11 range-based for loop for (auto &iter : expr_tree) iter.accept(print_visitor);
ExpressionTree exprTree = ...; ETVisitor printVisitor = new PrintVisitor(); Java for-each loop for (ComponentNode node : exprTree) node.accept(printVisitor);
295 See www.vincehuston.org/dp for many examples of patterns in C++ & Java

1 Expression Trees

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 Expression Trees

Uploaded by

Copyright:

Available Formats

A Case Study of Gang of Four (GoF) Patterns: Part 1

GoF Patterns Expression Tree Case Study

Topics Covered in this Part of the Module

GoF Patterns Expression Tree Case Study

Case Study: Expression Tree Processing App

3 ambiguity in algebraic expressions Expression trees are used to remove

GoF Patterns Expression Tree Case Study

Case Study: Expression Tree Processing App

1 Tree Node 0|1|2

Composite_ Add_Node Composite_ Multiply_Node

Composite_ Subtract_Node Composite_ Divide_Node

4 Despite decades of OO emphasis, algorithmic decomposition is still common

GoF Patterns Expression Tree Case Study

Case Study: Expression Tree Processing App

Commonality, & Variability (SCV) analysis in the context

Unary Node Leaf Nodes

SCV is a systematic software reuse method

GoF Patterns Expression Tree Case Study

Case Study: Expression Tree Processing App

Commonality, & Variability

(SCV) analysis in the context of a concrete example

Illustrate how patternoriented OO frameworks can be implemented in C++ & Java

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

7 See en.wikipedia.org/wiki/Binary_expression_tree for expression tree info

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

14 See en.wikipedia.org/wiki/Binary_expression_tree#Traversal for more info

GoF Patterns Expression Tree Case Study

Overview of Expression Tree Processing App

1. S = [5] 2. S = [-5] 3. S = [-5, 3] 4. S = [-5, 3, 4] 5. S = [-5, 7] 6. S = [-35]

push(node.item()) push(-pop()) push(node.item()) push(node.item()) push(pop()+pop()) push(pop()*pop())

GoF Patterns Expression Tree Case Study

A Case Study of Gang of Four (GoF) Patterns: Part 2

GoF Patterns Expression Tree Case Study

Topics Covered in this Part of the Module

GoF Patterns Expression Tree Case Study

How Not to Design an Expression Tree Application

GoF Patterns Expression Tree Case Study

How Not to Design an Expression Tree Application

Initialize Prompt User

Generally follows a divide &

i.e., general actions are

GoF Patterns Expression Tree Case Study

How Not to Design an Expression Tree Application

Generally follows a divide &

i.e., general actions are

Primary design components e.g., C functions

correspond to processing steps in execution sequence

GoF Patterns Expression Tree Case Study

Algorithmic Decomposition of Expression Tree