TDDB84: Lecture 7. State, Visitor, Interpreter, DSL. fredag 4 oktober 13

Similar documents
TDDB84 Design Patterns Lecture 09. State, Prototype, Visitor, Flyweight

A brief introduction to the State Pattern

TDDB84: Lecture 6. Adapter, Bridge, Observer, Chain of Responsibility, Memento, Command. fredag 4 oktober 13

The State Pattern. State Design Pattern: Motivation

The Strategy Pattern Design Principle: Design Principle: Design Principle:

TDDB84: Lecture 09. SOLID, Language design, Summary. fredag 11 oktober 13

TDDB84. Lecture 2. fredag 6 september 13

Design Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.)

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns

SDC Design patterns GoF

Using Design Patterns in Java Application Development

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

TDDB84: Lecture 5. Singleton, Builder, Proxy, Mediator. fredag 27 september 13

Design patterns. Jef De Smedt Beta VZW

Object-Oriented Oriented Programming

Object-Oriented Design

Trusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

MORE DESIGN PATTERNS CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 24 11/10/2011

Lecture 4: Observer Pattern, Event Library and Componentization

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011

Design Patterns: Structural and Behavioural

Think of drawing/diagramming editors. ECE450 Software Engineering II. The problem. The Composite pattern

1 Software Architecture

Exam in TDDB84: Design Patterns,

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1

Applying the Observer Design Pattern

OODP Session 4. Web Page: Visiting Hours: Tuesday 17:00 to 19:00

DESIGN PATTERN - INTERVIEW QUESTIONS

CSCI Object Oriented Design: Frameworks and Design Patterns George Blankenship. Frameworks and Design George Blankenship 1

Object-Oriented Design

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011

Software Design COSC 4353/6353 D R. R A J S I N G H

A Reconnaissance on Design Patterns

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Application Architectures, Design Patterns

Design Patterns Reid Holmes

COSC 3351 Software Design. Design Patterns Behavioral Patterns (I)

Testing3. State-based Testing

Design Patterns. Comp2110 Software Design. Department of Computer Science Australian National University. Second Semester

Lecture 17: Patterns Potpourri. Copyright W. Howden 1

CSCI 253. Overview. The Elements of a Design Pattern. George Blankenship 1. Object Oriented Design: Iterator Pattern George Blankenship

A few important patterns and their connections

Plan. A few important patterns and their connections. Singleton. Singleton: class diagram. Singleton Factory method Facade

Design Patterns. (and anti-patterns)

Object Oriented Methods with UML. Introduction to Design Patterns- Lecture 8

Design Patterns Reid Holmes

The Design Patterns Matrix From Analysis to Implementation

Design Patterns. An introduction

UNIT I Introduction to Design Patterns

An Introduction to Patterns

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1

administrivia today UML start design patterns Tuesday, September 28, 2010

Creational Design Patterns

Chapter 8, Design Patterns Visitor

CSE 70 Final Exam Fall 2009

Design Patterns. Lecture 10: OOP, autumn 2003

What are patterns? Design Patterns. Design patterns. Creational patterns. The factory pattern. Factory pattern structure. Lecture 10: OOP, autumn 2003

Writing your own Java I/O Decorator p. 102 Tools for your Design Toolbox p. 105 Exercise Solutions p. 106 The Factory Pattern Baking with OO

Object Oriented Paradigm

UNIT I Introduction to Design Patterns

Lecture 20: Design Patterns II

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.

Object-oriented Software Design Patterns

Applying the Decorator Design Pattern

Software Eningeering. Lecture 9 Design Patterns 2

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

However, some time later, suppose you decided to use DFS instead of BFS. So, you ll have to modify the code as follows:

Design Patterns Lecture 2

BFH/HTA Biel/DUE/Course 355/ Software Engineering 2

Design Patterns IV Structural Design Patterns, 1

Software Development Project. Kazi Masudul Alam

Design Patterns. Gunnar Gotshalks A4-1

Software Engineering

CS560. Lecture: Design Patterns II Includes slides by E. Gamma et al., 1995

INSTITUTE OF AERONAUTICAL ENGINEERING

The GoF Design Patterns Reference

Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns

Design patterns. OOD Lecture 6

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1

Applying Some Gang of Four Design Patterns CSSE 574: Session 5, Part 3

Slide 1. Design Patterns. Prof. Mirco Tribastone, Ph.D

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.

Software Reengineering Refactoring To Patterns. Martin Pinzger Delft University of Technology

Applying the Factory Method Design Pattern

Design Patterns Design patterns advantages:

CSCI 253. Overview. The Elements of a Design Pattern. George Blankenship 1. Object Oriented Design: Template Method Pattern. George Blankenship

Applying Design Patterns to SCA Implementations

Tecniche di Progettazione: Design Patterns

Interpreter Pattern Behavioural

Ownership in Design Patterns. Master's Thesis Final Presentation Stefan Nägeli

CSC207H: Software Design Lecture 6

Object-Oriented Concepts and Design Principles

Object-Oriented Design

What is a Pattern? Lecture 40: Design Patterns. Elements of Design Patterns. What are design patterns?

LECTURE NOTES ON DESIGN PATTERNS MCA III YEAR, V SEMESTER (JNTUA-R09)

Design Patterns. Dr. Rania Khairy. Software Engineering and Development Tool

Transcription:

TDDB84: Lecture 7 State, Visitor, Interpreter, DSL

Creational Prototype SOLID Structural Facade Flyweight Behavioral State Visitor Interpreter Summary The exam LE7 LE8 LE9 Several different patterns GUI apps LA4 LA5

Creational Prototype Structural Facade Flyweight SOLID How language design can make design patterns disappear (open classes, multiple dispatch, eval) Behavioral Domain-specific languages State Visitor Interpreter Fluent API:s as a demo of the Façadeprinciple Program to an interface, e.g. {1,2,3}.ShouldNot().Contain(EvenNumber) Summary The exam LE7 LE8 LE9 Several different patterns GUI apps LA4 LA5

State

dispense with ball NoQuarter insert HasQuarter turncrank Sold eject dispense without ball SoldOut

public void insertquarter() { if (state == HAS_QUARTER) { System.out.println("You can't insert another quarter"); } else if (state == NO_QUARTER) { state = HAS_QUARTER; System.out.println("You inserted a quarter"); } else if (state == SOLD_OUT) { System.out.println("You can't insert a quarter, the machine is sold out"); } else if (state == SOLD) { System.out.println("Please wait, we're already giving you a gumball"); } } public void ejectquarter() { if (state == HAS_QUARTER) { System.out.println("Quarter returned"); state = NO_QUARTER; } else if (state == NO_QUARTER) { System.out.println("You haven't inserted a quarter"); } else if (state == SOLD) { System.out.println("Sorry, you already turned the crank"); } else if (state == SOLD_OUT) { System.out.println("You can't eject, you haven't inserted a quarter yet"); } }

Demo

State: consequences

State: consequences + Allows classes to react differently deping on internal state

State: consequences + Allows classes to react differently deping on internal state + Describes all interaction results in one place, for each state

State: consequences + Allows classes to react differently deping on internal state + Describes all interaction results in one place, for each state - Introduces a lot of subclasses even if only parts of the behavior is modified

Visitor

tostring() (b+4) * a a=3 * eval() 18 b=2 getvars() [a,b] + a... b 4

Enter Visitor * + a b 4 Provide a traversal mechanism Let all nodes implement a single method for accepting an external visitor and calling the visitor with themselves as the argument Let the visitor do the job

Demo

Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Dep on abstractions, do not dep on concrete classes Classes should only have one reason to change Strive for loosely-coupled design

Compare GoF p. 335 & Head First p. 629 Who should do the traversal? Why does it matter?

Visitor: consequences

Visitor: consequences + A visitor can add functionality to an existing compound structure

Visitor: consequences + A visitor can add functionality to an existing compound structure - The traversal mechanism may be hidden from the visitor if the compound structure does not expose it, so the visitor cannot infer the relationship between one node and others

Visitor: consequences + A visitor can add functionality to an existing compound structure - - The traversal mechanism may be hidden from the visitor if the compound structure does not expose it, so the visitor cannot infer the relationship between one node and others Adding parts to the compound structure affects all visitors

Interpreter

Interpreter Composite Operation() Operation()

BNF Grammar expression ::= plus minus variable number plus ::= expression expression '+' minus ::= expression expression '-' variable ::= 'a' 'b' 'c'... 'z' digit = '0' '1'... '9' number ::= digit digit number Nonterminal expression Terminal expression

Demo

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp Philip Greenspun So what about using.. the language itself?

DSL Domain-Specific Language

require 'models/users' migrate do user=users.new user.person_nr=112233 user.name='ola' user.save!

class Migrator include Dsl require 'models/users' migrate do user=users.new user.person_nr=112233 user.name='ola' user.save! def initialize(f) load(f) def migrate(&block) @migration=block def run @migration.call

class Migrator require 'models/users' migrate do user=users.new user.person_nr=112233 user.name='ola' user.save! class Migrator include Dsl def initialize(f) load(f) def migrate(&block) @migration=block def run @migration.call

class Migrator def initialize require 'models/users' migrate do user=users.new user.person_nr=112233 user.name='ola' user.save! class Migrator include Dsl def initialize(f) load(f) def migrate(&block) @migration=block def run @migration.call

class Migrator def initialize require 'models/users' migrate do user=users.new user.person_nr=112233 user.name='ola' user.save! class Migrator include Dsl def initialize(f) load(f) def migrate(&block) @migration=block def run @migration.call

Interpreter: consequences

Interpreter: consequences + If your program does not have access to an interpreter/compiler for the language you write your program in, this is the design pattern for you

Interpreter: consequences + If your program does not have access to an interpreter/compiler for the language you write your program in, this is the design pattern for you + Allows you to create retricted languages with domain-specific features

Interpreter: consequences - + If your program does not have access to an interpreter/compiler for the language you write your program in, this is the design pattern for you + Allows you to create retricted languages with domain-specific features Introduces a lot of overhead for only moderately useful scripting constructs.

Exam question 4. Choose the best description of a Proxy: a) Allows substituting objects for other objects at run time b) Provides decoupling of an abstraction from its implementation c) Is used to transparently ext objects with functionality such as deferred initialization d) Can add responsibilities of objects dynamically at run time without affecting other objects