CSE 331 Software Design & Implementation Hal Perkins Winter 2013 Design Patterns Part 3 (Slides by Mike Ernst and David Notkin) 1.

Slides:



Advertisements
Similar presentations
Behavioral Pattern: Visitor C h a p t e r 5 – P a g e 224 When an algorithm is separated from an object structure upon which it operates, new operations.
Advertisements

Programming Languages Marjan Sirjani 2 2. Language Design Issues Design to Run efficiently : early languages Easy to write correctly : new languages.
CSE 331 SOFTWARE DESIGN & IMPLEMENTATION DESIGN PATTERNS II Autumn 2011.
CSE 143 Lecture 22: Advanced List Implementation (ADTs; interfaces; abstract classes; inner classes; generics; iterators)
INTERPRETER Main Topics What is an Interpreter. Why should we learn about them.
Inheritance. Extending Classes It’s possible to create a class by using another as a starting point  i.e. Start with the original class then add methods,
Fall 2007CS 2251 Trees Chapter 8. Fall 2007CS 2252 Chapter Objectives To learn how to use a tree to represent a hierarchical organization of information.
Liang, Introduction to Java Programming, Eighth Edition, (c) 2011 Pearson Education, Inc. All rights reserved Chapter 26 Binary Search Trees.
Visitor Pattern Jeff Schott CS590L Spring What is the Purpose of the Visitor Pattern ? n Represent an operation to be performed on the elements.
Design Patterns 2 Fawzi Emad Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
The Composite Pattern.. Composite Pattern Intent –Compose objects into tree structures to represent part-whole hierarchies. –Composite lets clients treat.
Interpreter By: Mahmoodreza Jahanseir Amirkabir University of Technology Computer Engineering Department Fall 2010.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns VI Composite, Iterator, and Visitor Patterns.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
CSE 331 Software Design & Implementation Dan Grossman Fall 2014 Data Abstraction: Abstract Data Types (ADTs) (Based on slides by Mike Ernst, David Notkin,
The Interpreter Pattern. Defining the Interpreter Intent Given a language, define a representation for its grammar along with an interpreter that uses.
Composite Design Pattern. Motivation – Dynamic Structure.
2.2 A Simple Syntax-Directed Translator Syntax-Directed Translation 2.4 Parsing 2.5 A Translator for Simple Expressions 2.6 Lexical Analysis.
Design Pattern Interpreter By Swathi Polusani. What is an Interpreter? The Interpreter pattern describes how to define a grammar for simple languages,
Go4 Visitor Pattern Presented By: Matt Wilson. Introduction 2  This presentation originated out of casual talk between former WMS “C++ Book Club” (defunct.
Spring 2010CS 2251 Trees Chapter 6. Spring 2010CS 2252 Chapter Objectives Learn to use a tree to represent a hierarchical organization of information.
Hello.java Program Output 1 public class Hello { 2 public static void main( String [] args ) 3 { 4 System.out.println( “Hello!" ); 5 } // end method main.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns IX Interpreter, Mediator, Template Method recap.
Advanced Compiler Design An Introduction to the Javali Compiler Framework Zoltán Majó 1.
Design Patterns Gang Qian Department of Computer Science University of Central Oklahoma.
CPS 506 Comparative Programming Languages Syntax Specification.
11/25/2015© Hal Perkins & UW CSEH-1 CSE P 501 – Compilers Implementing ASTs (in Java) Hal Perkins Winter 2008.
CSE 331 Software Design & Implementation Hal Perkins Winter 2012 Design Patterns Part 2 (Slides by Mike Ernst and David Notkin) 1.
Python Primer 1: Types and Operators © 2013 Goodrich, Tamassia, Goldwasser1Python Primer.
Behavioral Patterns CSE301 University of Sunderland Harry R Erwin, PhD.
LESSON 04.
Design patterns (part 2) CSE 331 University of Washington.
1 Languages and Compilers (SProg og Oversættere) Bent Thomsen Department of Computer Science Aalborg University With acknowledgement to Wei-Tek Tsai who’s.
1 Introduction  Algorithms  Data structures  Abstract data types  Programming with lists and sets © 2008 David A Watt, University of Glasgow Algorithms.
CS212: Object Oriented Analysis and Design Lecture 39: Design Pattern-III.
Application development with Java Lecture 21. Inheritance Subclasses Overriding Object class.
The Visitor Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
The Interpreter Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
Coming up: Inheritance
Interfaces and Inner Classes
1 Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L 9.1 – 9.4.
The Visitor Design Pattern and Java Tree Builder
1 Program Development  The creation of software involves four basic activities: establishing the requirements creating a design implementing the code.
Semantic Analysis II Type Checking EECS 483 – Lecture 12 University of Michigan Wednesday, October 18, 2006.
CSE 331 Software Design & Implementation Dan Grossman Spring 2015 Design Patterns, Part 2 (Based on slides by Mike Ernst, Dan Grossman, David Notkin, Hal.
Interpreter By: Mahmoodreza Jahanseir Amirkabir University of Technology Computer Engineering Department Fall 2010.
Chap. 7, Syntax-Directed Compilation J. H. Wang Nov. 24, 2015.
Syntax-Directed Definitions CS375 Compilers. UT-CS. 1.
Zach Tatlock / Winter 2016 CSE 331 Software Design and Implementation Lecture 21 Design Patterns 2.
Topic 2: binary Trees COMP2003J: Data Structures and Algorithms 2
CSE 403 Design Patterns (Part 2)
Structural Design Patterns
Software Engineering Fall 2005
Implementing ASTs (in Java) Hal Perkins Autumn 2009
CSE 331 Software Design & Implementation
Hierarchical Transformations Hierarchical Models Scene Graphs
Design Patterns A Case Study: Designing a Document Editor
CSE 331 Software Design and Implementation
Jim Fawcett CSE776 – Design Patterns Summer 2003
Design Pattern: Visitor
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
Behavioral Patterns Part-I introduction UNIT-VI
Implementing ASTs (in Java) Hal Perkins Autumn 2011
Lecture 12 CS203 1.
CSE 331 Software Design and Implementation
CSE 331 Software Design & Implementation
Software Design Lecture : 39.
16. Visitors SE2811 Software Component Design
16. Visitors SE2811 Software Component Design
Presentation transcript:

CSE 331 Software Design & Implementation Hal Perkins Winter 2013 Design Patterns Part 3 (Slides by Mike Ernst and David Notkin) 1

Outline Introduction to design patterns Creational patterns (constructing objects) Structural patterns (controlling heap layout)  Behavioral patterns (affecting object semantics) 2

Composite pattern Composite permits a client to manipulate either an atomic unit or a collection of units in the same way Good for dealing with part-whole relationships 3

Composite example: Bicycle Bicycle –Wheel Skewer Hub Spokes Nipples Rim Tape Tube Tire –Frame –Drivetrain –... 4

Methods on components class BicycleComponent { int weight(); float cost(); } class Skewer extends BicycleComponent { float price; float cost() { return price; } } class Wheel extends BicycleComponent { float assemblyCost; Skewer skewer; Hub hub;... float cost() { return assemblyCost + skewer.cost() + hub.cost() +...; } 5 Bicycle –Wheel Skewer Hub Spokes Nipples Rim Tape Tube Tire –Frame –Drivetrain –...

Composite example: Libraries Library Section (for a given genre) Shelf Volume Page Column Word Letter interface Text { String getText(); } class Page implements Text { String getText() {... return the concatenation of the column texts... } 6

Traversing composites Goal: perform operations on all parts of a composite Idea: generalize the notion of an iterator – process the components of a composite in an order appropriate for the application Example: arithmetic expressions in Java –How do we represent, say, x=foo*b+c/d; –How do we traverse/process these expressions? 7

Representing Java code x = foo * b + c / d; 8 x + = * bfoo / dc

Abstract syntax tree (AST) for Java code class PlusOp extends Expression { // + operation Expression leftExp; Expression rightExp; } class VarRef extends Expression { // variable reference String varname; } class EqualOp extends Expression { // equality test a==b; Expression lvalue; // left-hand side; "a" in "a==b" Expression rvalue; // right-hand side; "b" in "a==b" } class CondExpr extends Expression { // a?b:c Expression condition; Expression thenExpr; // value of expression if a is true Expression elseExpr; // value of expression if a is false } 9

Object model vs. type hierarchy AST for "a + b": Class hierarchy for Expression: 10

Operations on abstract syntax trees Need to write code in each of the cells of this table: Question: Should we group together the code for a particular operation or the code for a particular expression? i.e., do we package the operations in rows or columns? (A separate issue: given an operation and an expression, how to select the proper piece of code?) 11 Objects CondExprEqualOp Operations typecheck pretty-print

Interpreter and visitor patterns Interpreter: collects code for similar objects, spreads apart code for similar operations Makes it easy to add objects, hard to add operations Visitor (or more generally Procedural): collects code for similar operations, spreads apart code for similar objects Makes it easy to add operations, hard to add objects The visitor pattern is the most common procedural pattern Both interpreter and procedural have classes for objects The code for operations is similar The question is where to place that code Selecting between interpreter and procedural: Are the algorithms central, or are the objects? (Is the system operation-centric or object-centric?) What aspects of the system are most likely to change? 12

Interpreter pattern Add a method to each class for each supported operation class Expression {... Type typecheck(); String prettyPrint(); } class EqualOp extends Expression {... Type typecheck() {... } String prettyPrint() {... } } class CondExpr extends Expression {... Type typecheck() {... } String prettyPrint() {... } } 13 Dynamic dispatch chooses the right implementation, for a call like someExpr.typeCheck()

Procedural pattern Create a class per operation, with a method per operand type class Typecheck { // typecheck "a?b:c" Type tcCondExpr(CondExpr e) { Type condType = tcExpression(e.condition); // type of "a" Type thenType = tcExpression(e.thenExpr); // type of "b" Type elseType = tcExpression(e.elseExpr); // type of "c" if ((condType == BoolType) && (thenType == elseType)) { return thenType; } else { return ErrorType; } } // typecheck "a==b" Type tcEqualOp(EqualOp e) {... } 14 How to invoke the right implementation?

Definition of tcExpression (in procedural pattern) class Typecheck {... Type tcExpression(Expression e) { if (e instanceof PlusOp) { return tcPlusOp((PlusOp)e); } else if (e instanceof VarRef) { return tcVarRef((VarRef)e); } else if (e instanceof EqualOp) { return tcEqualOp((EqualOp)e); } else if (e instanceof CondExpr) { return tcCondExpr((CondExpr)e); } else } 15 Maintaining this code is tedious and error-prone. The cascaded if tests are likely to run slowly. This code must be repeated in PrettyPrint and every other operation class.

Visitor pattern: A variant of the procedural pattern Visitor encodes a traversal of a hierarchical data structure Nodes (objects in the hierarchy) accept visitors Visitors visit nodes (objects) class Node { void accept(Visitor v) { for each child of this node { child.accept(v); } v.visit(this); } class Visitor { void visit(Node n) { perform work on n } 16 n.accept(v) traverses the structure rooted at n, performing v 's operation on each element of the structure What happened to all the instanceof operations?

Sequence of calls to accept and visit a.accept(v) b.accept(v) d.accept(v) v.visit(d) e.accept(v) v.visit(e) v.visit(b) c.accept(v) f.accept(v) v.visit(f) v.visit(c) v.visit(a) Sequence of calls to visit: d, e, b, f, c, a 17

Implementing visitor You must add definitions of visit and accept visit might count nodes, perform typechecking, etc. It is easy to add operations (visitors), hard to add nodes (modify each existing visitor) Visitors are similar to iterators: each element of the data structure is presented in turn to the visit method –Visitors have knowledge of the structure, not just the sequence 18

Calls to visit cannot communicate with one another Can use an auxiliary data structure Another solution: move more work into the visitor itself class Node { void accept(Visitor v) { v.visit(this); } } class Visitor { void visit(Node n) { for each child of this node { child.accept(v); } perform work on n } } Information flow is clearer (if visitor depends on children) Traversal code repeated in all visitors (acceptor is extraneous) 19