Patterns

CS 251 INTERMEDIATE SOFTWARE DESIGN SPRING 2011 Expression Tree Putting it all together

DESIGN PROBLEMS AND PATTERN-ORIENTED SOLUTIONS Binary Nodes

Unary Node Leaf Nodes

Design Problem

Pattern(s)

Expression tree structure Composite Encapsulating variability Bridge and simplifying memory management Tree printing and evaluation

Iterator and Visitor

Consolidating user operations

Command

Ensuring correct protocol for commands

State

Consolidating creation of Variabilities

Abstract Factory and Factory Method

Parsing expressions and creating expression tree

Interpreter and Builder

DESIGN PROBLEMS AND PATTERN-ORIENTED SOLUTIONS Design Problem Pattern(s) Binary Nodes

Unary Node Leaf Nodes

Driving the application event flow

Reactor

Supporting multiple operation modes

Template Method and Strategy

Centralizing global objects effectively

Singleton

Implementing STL iterator semantics

Prototype

Eliminating loops via the STL std::for_each() algorithm

Adapter

Provide no-op commands

Null Object

None of these patterns are restricted to expression tree applications…

TREE STRUCTURE AND CREATION PATTERNS Interpreter Expression_Tree_ Context

Expression_Tree

>

Interpreter_Context

Interpreter

Component_Node

Symbol

Composite_ Unary_Node

Leaf_Node

>

Number

Operator

Unary_Operator

Add

Substract

Negate

> Composite_ Binary_Node

Composite_ Add_Node

Composite_ Substract_Node

Composite_ Multiply_Node

Composite

Composite_ Negate_Node

>

Multiply

Divide

Composite_ Divide_Node

Builder

TREE TRAVERSAL PATTERNS

Visitor

Iterator

Expression_Tree

Component_Node

>

Visitor

> Expression_Tree_ Iterator

LQueue

Bridge

Expression_Tree_ Iterator_Impl

Evaluation_Visitor

Print_Visitor

Level_Order_Expression_ Tree_Iterator_Impl In_Order_Expression_ Tree_Iterator_Impl

std::stack

Post_Order_Expression_ Tree_Iterator_Impl Pre_Order_Expression_ Tree_Iterator_Impl

COMMAND AND FACTORY PATTERNS AbstractFactory

Expression_Tree_ Event_Handler

Expression_Tree_ Command_Factory

Expression_Tree_Command_ Factory_Impl

Concrete_Expression_Tree_ Command_Factory_Impl

>

*

1

Macro_Command

Expression_Tree_ Command

Expression_Tree_ Command_Impl

Print_Command

Set_Command

Format_Command

Command

Expression_Tree_ Context

Quit_Command

Expr_Command

Null_Command

Eval_Command

STATE PATTERN Expression_Tree_ Context

Expression_Tree_ State

Uninitialized_ State

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

>

Interpreter

APPLICATION STRUCTURE PATTERNS Reactor Reactor

Expression_Tree_ Command_Factory

>

Expression_Tree_ Command

Event_Handler

Expression_Tree_ Event_Handler

Verbose_Expression_ Tree_Event_Handler

Macro_Expression_ Tree_Event_Handler

Strategy

Singleton Options

Expression_Tree_ Context

BUILDER VS. FACTORY   

 



Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately. Builder often builds a Composite. Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed. Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

BUILDER VS. FACTORY 

In the Factory pattern, the factory is in charge of creating various subtypes of an object depending on the needs.

The user of a factory method doesn't need to know the exact subtype of that object. An example of a factory method createCar might return a Ford or a Honda typed object.



In the Builder pattern, different subtypes are also created by a builder method, but the composition of the objects might differ within the same subclass.

To continue the car example you might have a createCar builder method which creates a Honda-typed object with a 4 cylinder engine, or a Honda-typed object with 6 cylinders. The builder pattern allows for this finer granularity.

EXPRESSION TREE EXAMPLE Component_Node.h Component_Node.cpp Composite_Unary_Node.h Composite_Unary_Node.cpp Composite_Negate_Node.h Composite_Negate_Node.cpp Composite_Binary_Node.h Composite_Binary_Node.cpp Composite_Add_Node.h Compsite_Add_Node.cpp Composite_Subtract_Node.h Composite_Subtract_Node.cpp Composite_Divide_Node.h Composite_Divide_Node.cpp Composite_Multiply_Node.h Composite_Multiply_Node.cpp Evaluation_Visitor.h Evaluation_Visitor.cpp Event_Handler.h Event_Handler.cpp Expression_Tree.h Expression_Tree.cpp Expression_Tree_Command.h Expression_Tree_Command.cpp

getOpt.h getOpt.cpp Interpreter.h Interpreter.cpp Leaf_Node.h Leaf_Node.cpp LQueue.h LQueue.cpp LStack.h LStack.cpp Main.cpp Makefile Observer.h Options.h Options.cpp Print_Visitor.h Print_Visitor.cpp Reactor.h Reactor.cpp RefCounter.h RefCounter.cpp

Expression_Tree_Command_Factory_Impl.h Expression_Tree_Command_Factory_Impl.cpp

Visitor.h Visitor.cpp

Expression_Tree_Command_Impl.h Expression_Tree_Command_Impl.cpp Expression_Tree_Command_Factory.h Expression_Tree_Command_Factory.cpp Expression_Tree_Context.h Expression_Tree_Context.cpp Expression_Tree_Event_Handler.h Expression_Tree_Event_Handler.cpp Expression_Tree_Iterator.h Expression_Tree_Iterator.cpp Expression_Tree_Iterator_Impl.h Expression_Tree_Iterator_Impl.cpp Expression_Tree_State.h Expression_Tree_State.cpp

Strategy.h TypeDefs.h

PART III: WRAP-UP: OBSERVATIONS Patterns and frameworks support  design/implementation at a more abstract level  treat many class/object interactions as a unit  often beneficial after initial design  targets for class refactorings  Variation-oriented design/implementation  consider what design aspects are variable  identify applicable pattern(s)  vary patterns to evaluate tradeoffs  repeat

Patterns are applicable in all stages of the OO lifecycle – analysis, design, and reviews – realization and documentation – reuse and refactoring

PART III: WRAP-UP: CAVEATS

Do not apply patterns and frameworks blindly • Added indirection can yield increased complexity, cost • Understand patterns to learn how to better develop/use frameworks

Resist branding everything a pattern • Articulate specific benefits • Demonstrate wide applicability • Find at least three existing examples from code other than your own!

Pattern and framework design even harder than OO design!

CONCLUDING REMARKS Patterns and frameworks promote  Integrated design and implementation reuse  uniform design vocabulary  understanding, restructuring, and team communication  a basis for automation  a “new” way to think about OO design and implementation

PATTERN REFERENCES Books

Timeless Way of Building, Alexander, ISBN 0-19-502402-8

A Pattern Language, Alexander, 0-19-501-919-9

Design Patterns, Gamma, et al., 0-201-63361-2 CD version 0-201-63498-8

Pattern-Oriented Software Architecture, Vol. 1, Buschmann, et al., 0-471-95869-7 Pattern-Oriented Software Architecture, Vol. 2, Schmidt, et al., 0-471-60695-2

Pattern-Oriented Software Architecture, Vol. 3, Jain & Kircher, 0-470-84525-2 Pattern-Oriented Software Architecture, Vol. 4, Buschmann, et al., 0-470-05902-8

Pattern-Oriented Software Architecture, Vol. 5, Buschmann, et al., 0-471-48648-5

PATTERN REFERENCES (CONT’D) More Books Analysis Patterns, Fowler; 0-201-89542-0 Concurrent Programming in Java, 2nd ed., Lea, 0-201-31009-0 Pattern Languages of Program Design Vol. 1, Coplien, et al., eds., ISBN 0-201-60734-4 Vol. 2, Vlissides, et al., eds., 0-201-89527-7 Vol. 3, Martin, et al., eds., 0-201-31011-2 Vol. 4, Harrison, et al., eds., 0-201-43304-4 Vol. 5, Manolescu, et al., eds., 0-321-32194-4 AntiPatterns, Brown, et al., 0-471-19713-0 Applying UML & Patterns, 2nd ed., Larman, 0-13-092569-1 Pattern Hatching, Vlissides, 0-201-43293-5 The Pattern Almanac 2000, Rising, 0-201-61567-3

PATTERN REFERENCES (CONT’D)

Even More Books Small Memory Software, Noble & Weir, 0-201-59607-5 Microsoft Visual Basic Design Patterns, Stamatakis, 1-572-319577 Smalltalk Best Practice Patterns, Beck; 0-13-476904-X The Design Patterns Smalltalk Companion, Alpert, et al., 0-201-18462-1 Modern C++ Design, Alexandrescu, ISBN 0-201-70431-5 Building Parsers with Java, Metsker, 0-201-71962-2 Core J2EE Patterns, Alur, et al., 0-130-64884-1 Design Patterns Explained, Shalloway & Trott, 0-201-71594-5 The Joy of Patterns, Goldfedder, 0-201-65759-7 The Manager Pool, Olson & Stimmel, 0-201-72583-5

PATTERN REFERENCES (CONT’D) Early Papers

“Object-Oriented Patterns,” P. Coad; Comm. of the ACM, 9/92 “Documenting Frameworks using Patterns,” R. Johnson; OOPSLA ’92 “Design Patterns: Abstraction & Reuse of Object-Oriented Design,” Gamma, Helm, Johnson, Vlissides, ECOOP ’93

Articles

Java Report, Java Pro, JOOP, Dr. Dobb’s Journal, Java Developers Journal, C++ Report

How to Study Patterns

http://www.industriallogic.com/papers/learning.html

PATTERN-ORIENTED CONFERENCES PLoP 2009: Pattern Languages of Programs October 2009, Collocated with OOPSLA EuroPLoP 2010, July 2010, Kloster Irsee, Germany … See hillside.net/conferences/ for up-to-the-minute info

MAILING LISTS [email protected]: present & refine patterns [email protected]: general discussion [email protected]: discussion on Design Patterns [email protected]: discussion on Pattern-Oriented Software Architecture [email protected]: discussion on user interface patterns [email protected]: discussion on patterns for business processes [email protected]: discussion on patterns for distributed systems See http://hillside.net/patterns/mailing.htm for an up-to-date list.