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

Similar documents
TDDB84. Summary & wrap-up & some tips & some design patterns & some other stuff. tisdag 20 oktober 15

TDDB84. Lecture 2. fredag 6 september 13

TDDB84 Design Patterns Lecture 06

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

UNIT I Introduction to Design Patterns

Design Patterns Reid Holmes

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

SDC Design patterns GoF

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

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

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

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

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

FACADE & ADAPTER CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 7 09/13/2011

UNIT I Introduction to Design Patterns

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

Introduction to Software Engineering: Object Design I Reuse & Patterns

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

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

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

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

Using Design Patterns in Java Application Development

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

Applying the Observer Design Pattern

Design Patterns: Structural and Behavioural

Software Eningeering. Lecture 9 Design Patterns 2

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

Design Patterns Lecture 2

SYLLABUS CHAPTER - 1 [SOFTWARE REUSE SUCCESS FACTORS] Reuse Driven Software Engineering is a Business

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

INSTITUTE OF AERONAUTICAL ENGINEERING

Design Patterns. An introduction

Object-Oriented Oriented Programming

DESIGN PATTERN - INTERVIEW QUESTIONS

Lecture 4: Observer Pattern, Event Library and Componentization

CSC207H: Software Design Lecture 6

Brief Note on Design Pattern

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

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

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

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

A Reconnaissance on Design Patterns

Design patterns. Jef De Smedt Beta VZW

C++ for System Developers with Design Pattern

Object-oriented Software Design Patterns

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

Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns

The Design Patterns Matrix From Analysis to Implementation

Chapter 8, Design Patterns Visitor

Design Pattern and Software Architecture: IV. Design Pattern

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

Design Pa*erns. + Anima/on Undo/Redo Graphics and Hints

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

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

CS 349 / SE 382 Design Patterns. Professor Michael Terry January 21, 2009

CS/CE 2336 Computer Science II

Object Oriented Paradigm

Applying Design Patterns to SCA Implementations

Pro Objective-C Design Patterns for ios

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

UP Requirements. Software Design - Dr Eitan Hadar (c) Activities of greater emphasis in this book. UP Workflows. Business Modeling.

Design Patterns. (and anti-patterns)

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

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

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

Design Patterns Reid Holmes

Design Patterns. Hausi A. Müller University of Victoria. Software Architecture Course Spring 2000

Socket attaches to a Ratchet. 2) Bridge Decouple an abstraction from its implementation so that the two can vary independently.

1 Software Architecture

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

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

Object-Oriented Design

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

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

Creational. Structural

Nat. Thomas Software Engineering Telephonics Inc. Long Island IEEE Lecture Series

Design Patterns. SE3A04 Tutorial. Jason Jaskolka

Lecture 17: Patterns Potpourri. Copyright W. Howden 1

CS 2720 Practical Software Development University of Lethbridge. Design Patterns

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

2.1 Design Patterns and Architecture (continued)

Topics. Software Process. Agile. Requirements. Basic Design. Modular Design. Design Patterns. Testing. Quality. Refactoring.

Software Design Patterns. Aliaksei Syrel

Object-Oriented Design

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

Creational Design Patterns

Design Patterns (Part 2) CSCE Lecture 18-10/25/2016 (Partially adapted from Head First Design Patterns by Freeman, Bates, Sierra, and Robson)

Development and Implementation of Workshop Management System Application to Explore Combing Multiple Design Patterns

I, J. Key-value observing (KVO), Label component, 32 text property, 39

2.1 Design Patterns and Architecture (continued)

Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University

Overview of Patterns: Introduction

Exam in TDDB84: Design Patterns,

Application Architectures, Design Patterns

Lecture 20: Design Patterns II

Design Patterns and Frameworks Command

Design patterns generic models

What is Design Patterns?

An Introduction to Patterns

Design Patterns. Observations. Electrical Engineering Patterns. Mechanical Engineering Patterns

Transcription:

TDDB84: Lecture 6 Adapter, Bridge, Observer, Chain of Responsibility, Memento, Command

Creational Abstract Factory Singleton Builder Structural Composite Proxy Bridge Adapter Template method Behavioral Iterator Mediator Chain of responsibility Observer Observer LE3 LE4 LE5 LE6 Creational patterns Structural patterns LA1 LA2 LA3

Creational Abstract Factory Singleton Builder Structural Composite Proxy Bridge Adapter Template method Behavioral Iterator Mediator Chain of responsibility Observer Observer LE3 LE4 LE5 LE6 Creational patterns Structural patterns LA1 LA2 LA3

Adapter

Class Adapter Object Adapter

Multiple back-end objects Client Target do() Adapter -adaptee1 -adaptee2 do() Adaptee1 +perform() Adaptee2 +perform()

Multiple back-end methods Client Target do() Adapter -adaptee do() Adaptee1 +foo() +bar() adaptee.foo() adaptee.bar()

public interface Duck { public void quack(); public void fly(); } public interface Turkey { public void gobble(); public void fly(); } public class TurkeyAdapter implements Duck { Turkey turkey; } public TurkeyAdapter(Turkey turkey) { this.turkey = turkey; } public void quack() { turkey.gobble(); } public void fly() { for(int i=0; i < 5; i++) { turkey.fly(); } } public class DuckAdapter implements Turkey { Duck duck; Random rand; } public DuckAdapter(Duck duck) { this.duck = duck; rand = new Random(); } public void gobble() { duck.quack(); } public void fly() { if (rand.nextint(5) == 0) { duck.fly(); } }

Demo

Adapter: consequences

Adapter: consequences + Isolates interface changes to the adapter class

Adapter: consequences + Isolates interface changes to the adapter class - Class adapters require target interfaces or multiple inheritance in the language

Bridge

TV

TV Samsung LG

TV Samsung LG Logitech Harmony On() Off() On() Off()

TV Samsung LG Logitech Harmony On() Off() On() Off() One For All On() Off() On() Off()

TV Samsung LG Logitech Harmony On() Off() On() Off() Remote One For All On() Off() On() Off()

Message type

Message type Password recovery Signup

Message type Password recovery Signup E-mail Send() Send()

Message type Password recovery Signup E-mail Send() Send() SMS Send() Send()

Message type Password recovery Signup E-mail Send() Send() Transmission type SMS Send() Send()

Abstraction == That which we (should) care about

Bridge Strategy Intent Collaborations Decouple two class hierarchies (abstraction/ implementation) The Bridge forwards requests to the Implementor Allow for exchangeable algorithms The Context and Strategy collaborate, passing data between them

Bridge Adapter Intent Decouple two class hierarchies (abstraction/ implementation) Convert an existing class to fit a new interface Applicability In a new system In an existing system

Demo

Design principles 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 Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change

Bridge: consequences

Bridge: consequences + Lets two class hierarchies with common superclasses vary independently

Bridge: consequences + Lets two class hierarchies with common superclasses vary independently - If some implementation classes do not support an abstract concept, the abstraction breaks

Observer

Weather Station Humidity Display Average Temp Display

Weather Station Humidity Display Average Temp Display subscribe() subscribe()

Weather Station Humidity Display Average Temp Display subscribe() subscribe() publish() publish()

Weather Station Humidity Display Average Temp Display subscribe() subscribe() publish() publish() unsubscribe() publish()

Subject

Subject Concrete Observer

Demo

Mediator vs Observer

Design principles 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 Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change Strive for loosely-coupled design

Chain of Responsibility

SPAM Filter isspam(message)

SPAM Filter isspam(message) reject Message rejected

SPAM Filter isspam(message) accept Size Filter istoolarge(message) reject Message rejected

SPAM Filter isspam(message) accept Size Filter istoolarge(message) accept Sorting Filter sort(message) reject reject Message rejected

SPAM Filter isspam(message) accept Size Filter istoolarge(message) accept Sorting Filter sort(message) process reject reject Message arrived Message rejected

SPAM Filter isspam(message) accept Size Filter istoolarge(message) accept Sorting Filter sort(message) process reject reject Message arrived Message rejected

Examples Logging Input management in GUI:s

Demo

CoR: consequences

CoR: consequences + provides the Observer with more control over invocation of targets

CoR: consequences + provides the Observer with more control over invocation of targets - A handler does not know if it will receive a message, depending on the behavior of other handlers in the chain

Memento

Iterative Optimizer iteration current target value current solution Optimize() Abort() GetState() SetState() SolverMemento iteration current target value current solution Client - memento - optimizer Optimize() Abort() ResetOptimizer(SolverMemento)

Iterative Optimizer iteration current target value current solution Optimize() Abort() GetState() SetState() SolverMemento iteration current target value current solution Client - memento - optimizer Optimize() Abort() ResetOptimizer(SolverMemento)

Mementos in GUI:s - Undo/Redo

Mementos in GUI:s - Undo/Redo 1 gi User Name Ginnie Age 24

Mementos in GUI:s - Undo/Redo User Name Age gi Ginnie 24 1 User Name Age 2 gi jo Ginnie Johnny 24 37

Mementos in GUI:s - Undo/Redo User Name Age gi Ginnie 24 1 2 gi jo User Name Ginnie Johnny Age 24 37 3 Undo Redo Cut Copy Paste Paste special... Delete Select All

Mementos in GUI:s - Undo/Redo User Name Age gi Ginnie 24 1 2 gi jo User Name Ginnie Johnny Age 24 37 3 Undo Redo Cut Copy Paste Paste special... 4 gi User Name Ginnie Age 24 Delete Select All

Demo

Memento: consequences

Memento: consequences + Can externalize object state for later restoration within the lifetime of the object

Memento: consequences + Can externalize object state for later restoration within the lifetime of the object + Encapsulates access to the objects inner state

Memento: consequences - + Can externalize object state for later restoration within the lifetime of the object + Encapsulates access to the objects inner state Depending on implementation, access to private fields requires memento classes as inner/friend classes to each domain class

Command

Command Client Waiter Order Chef Order Place Order Cook

Remote control Joe s Ultimate Remote Control On Off On Off On Off On Off On Off On Off On Off Undo TDDB84 Design Patterns

Remote control Joe s Ultimate Remote Control Fan High() Low() Off() GetSpeed() On Off On Off On Off On Off On Off On Off On Off Undo TDDB84 Design Patterns

Remote control Joe s Ultimate Remote Control Fan High() Low() Off() GetSpeed() On Off On Off On Off On Off On Off On Off On Off Undo TV TurnOn() TurnOff() SetChannel() TDDB84 Design Patterns

Remote control Joe s Ultimate Remote Control Fan High() Low() Off() GetSpeed() On Off On Off On Off On Off On Off On Off On Off Undo On() Off() Dim() Lamp TV TurnOn() TurnOff() SetChannel() TDDB84 Design Patterns

Client Invoker -command perform() Command +execute() Receiver +perform() Concrete Command -receiver

Invoker

Client

Concrete Commands

Command

Receiver

Demo

Command: consequences

+ Allows extensions of commands Command: consequences

+ Allows extensions of commands Command: consequences + Decouples the execution from the specification of the command

Command: consequences + Allows extensions of commands + Decouples the execution from the specification of the command - Bad design if not needed!

Command: consequences + Allows extensions of commands + Decouples the execution from the specification of the command - - Bad design if not needed! May be confusing if it removes the receiver from responsibilities

Next lecture

Creational Prototype Structural Facade Flyweight Behavioral Command Interpreter Memento State Visitor LE7 LE8 LE9 Several different patterns GUI apps LA4 LA5

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