Design Patterns ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University.

Slides:



Advertisements
Similar presentations
18-1 Verifying Object Behavior and Collaboration Role playing – the act of simulating object behavior and collaboration by acting out an object’s behaviors.
Advertisements

Design Patterns Copyright © Vyacheslav Mukhortov, Nikita Nyanchuk-Tatarskiy, Copyright © INTEKS LLC,
Computer Science 313 – Advanced Programming Topics.
DESIGN PATTERNS OZGUR RAHMI DONMEZ.
Dr. Tom WayCSC Design Patterns & Anti-Patterns CSC 4700 Software Engineering.
George Blank University Lecturer. CS 602 Java and the Web Object Oriented Software Development Using Java Chapter 10.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 17 Object Oriented Design 3.
CS CS 5150 Software Engineering Lecture 17 Object Oriented Design 3.
Iterators T.J. Niglio Computer & Systems Engineering Fall 2003 Software Design & Documentation Object Behavioral.
Dept. of Computer Engineering, Amirkabir University of Tech. 1 Design Patterns Dr. Noorhosseini Introduction.
Design Patterns CS is not simply about programming
1 CS 501 Spring 2008 CS 501: Software Engineering Lectures 17 & 18 Object Oriented Design 3 & 4.
CS CS 5150 Software Engineering Lecture 16 Object Oriented Design 2.
CS CS 5150 Software Engineering Lecture 16 Object Oriented Design 2.
ECE 355 Design Patterns Tutorial Part 2 (based on slides by Ali Razavi) Presented by Igor Ivković
1 CS 501 Spring 2007 CS 501: Software Engineering Lectures 17 & 18 Object Oriented Design 3 & 4.
Design Patterns academy.zariba.com 1. Lecture Content 1.What are Design Patterns? 2.Creational 3.Structural 4.Behavioral 5.Architectural 6.Design Patterns.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010.
Composite Design Pattern. Motivation – Dynamic Structure.
Design Patterns Standardized Recurring model Fits in many location Opposite of customization Fundamental types of pattern Choose and use as desired and.
BDP Behavioral Pattern. BDP-2 Behavioral Patters Concerned with algorithms & assignment of responsibilities Patterns of Communication between Objects.
05 - Patterns Intro.CSC4071 Design Patterns Designing good and reusable OO software is hard. –Mix of specific + general –Impossible to get it right the.
CS 325: Software Engineering March 17, 2015 Applying Patterns (Part A) The Façade Pattern The Adapter Pattern Interfaces & Implementations The Strategy.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Design Patterns Part two. Structural Patterns Concerned with how classes and objects are composed to form larger structures Concerned with how classes.
Chapter 26 GoF Design Patterns. The Adapter Design Pattern.
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
Mediator Pattern and Multiuser Protection Billy Bennett June 8 th, 2009.
Design ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University.
Design Patterns CSCI 5801: Software Engineering. Design Patterns.
Software Design Patterns (1) Introduction. patterns do … & do not … Patterns do... provide common vocabulary provide “shorthand” for effectively communicating.
Computing IV Singleton Pattern Xinwen Fu.
Object Oriented Software Engineering Chapter 16 and 17 review 2014/06/03.
Structural Design Patterns
ECE450S – Software Engineering II
1 A Brief Introduction to Design Patterns Based on materials from Doug Schmidt 1.
Design Patterns CSIS 3701: Advanced Object Oriented Programming.
More Design Patterns Horstmann ch.10.1,10.4. Design patterns Structural design patterns –Adapter –Composite –Decorator –Proxy Behavioral design patterns.
1 Design Patterns Object-Oriented Design. 2 Design Patterns 4Reuse of design knowledge and experience 4Common in many engineering disciplines 4Avoids.
08 - StructuralCSC4071 Structural Patterns concerned with how classes and objects are composed to form larger structures –Adapter interface converter Bridge.
Structural Patterns1 Nour El Kadri SEG 3202 Software Design and Architecture Notes based on U of T Design Patterns class.
Linzhang Wang Dept. of Computer Sci&Tech, Nanjing University The Strategy Pattern.
Proxy.
OO Methodology Elaboration Iteration 2 - Design Patterns -
Behavioral Patterns CSE301 University of Sunderland Harry R Erwin, PhD.
Software Design Patterns Curtsy: Fahad Hassan (TxLabs)
Design Patterns. 1 Paradigm4 Concepts 9 Principles23 Patterns.
Design Patterns Introduction
BEHAVIORAL PATTERNS 13-Sep-2012 Presenters Sanjeeb Kumar Nanda & Shankar Gogada.
Proxy Pattern defined The Proxy Pattern provides a surrogate or placeholder for another object to control access to it by creating a representative object.
CS 210 Proxy Pattern Nov 16 th, RMI – A quick review A simple, easy to understand tutorial is located here:
Chapter 8 Object Design Reuse and Patterns. More Patterns Abstract Factory: Provide manufacturer independence Builder: Hide a complex creation process.
CS 5150 Software Engineering Lecture 16 Program Design 3.
Adaptor Bridge Composite UNIT-IV1 Repeated key points for Structural Patterns (Intent, Motivation, Also Known As…) Code Examples Reference
PROTOTYPE. Design Pattern Space Purpose ScopeCreationalStructuralBehavioral ClassFactory MethodAdapterInterpreter Template Method ObjectAbstract factory.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
7 April 2004CSci 210 Spring Design Patterns 2 CSci 210.
Strategy Design Pattern
Software Architecture and Quality BY
Chapter 10 Design Patterns.
Software Design Patterns
MPCS – Advanced java Programming
A Brief Introduction to Design Patterns
Introduction to Design Patterns
object oriented Principles of software design
Design ECE 417/617: Elements of Software Engineering Stan Birchfield
Design Patterns Satya Puvvada Satya Puvvada.
Structural Pattern part-I introduction
Informatics 122 Software Design II
Presentation transcript:

Design Patterns ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

What is a Design Pattern? A design pattern –abstracts a recurring design structure –comprises class and/or object dependencies, structures, interactions, or conventions –distills design experience

Re-use Code re-use –Don’t reinvent the wheel –Requires clean, elegant, understandable, general, stable code –leverage previous work Design re-use –Don’t reinvent the wheel –Requires a precise understanding of common, recurring designs –leverage previous work

Some design patterns Abstract factory Adapter Bridge Command Composite Façade Subject / Observer Proxy Strategy

Subject-observer [from Vlissides]

Subject-observer (cont.) Subject Register(Observer) Unregister(Observer) NotifyAll() Observer OnUpdate() 1 * for all o in observers { o.OnUpdate() }

Subject-observer (cont.) Subject Register(Observer) Unregister(Observer) NotifyAll() Observer virtual OnUpdate() 1 * for all o in observers { o.OnUpdate() } ConcreteSubjectConcreteObserver virtual OnUpdate()

Model / view / controller (MVC) Controller Model View (displays data) (mediates) (holds data) { Model m; Controller c(&m); View v(&c); } calls Register() Main View Controller Model Create() Register()

MVC (cont.) Subject Register(Observer) Unregister(Observer) NotifyAll() Observer virtual OnUpdate() 1 * for all o in observers { o.OnUpdate() } ControllerView virtual OnUpdate()

MVC (cont.) class Observer { protected: virtual void OnUpdate(MsgId message_id) = 0; }; class Subject { public: enum MsgId {}; void RegisterObserver(Observer* obs); virtual void NotifyAllObservers(MsgId message_id) { for (int i=0 ; i<m_observers.size() ; i++) { m_observers[i]->OnUpdate(message_id); } private: std::vector m_observers; };

MVC (cont.) class Controller : public Subject { Controller(Data* d) : m_data(d) {} const Data* GetData() const; void AddSphere(const Sphere& s) { m_data->AddSphere(s); NotifyAllObservers(ADD_SPHERE); } private: Data* m_data; };

MVC (cont.) class MainWnd : public Observer, CWnd { public: MainWnd(Controller* c) : m_controller(c) { c.Register(this); } virtual void OnUpdate(int message_id) { switch (message_id) { case Subject::ADD_SPHERE:... } private: Controller* m_controller; };

Adapter You have –legacy code –current client Adapter changes interface of legacy code so client can use it Adapter fills the gap b/w two interfaces No changes needed for either –legacy code, or –client

Adapter (cont.) class NewTime { public: int GetTime() { return m_oldtime.get_time() * ; } private: OldTime m_oldtime; };

Command You have commands that need to be –executed, –undone, or –queued Command design pattern separates –Receiver from Invoker from Commands All commands derive from Command and implement do(), undo(), and redo()

Facade You –have a set of related classes –want to shield the rest of the system from these details Facade provides a simplified interface Encapsulates a subsystem

Composite You want uniformly to treat –items (atomic elements), and –groups (containing items or other groups) Composite interface specifies operations that are shared between items and groups Examples: hierarchy of files and directories, groups of drawable elements

Composite (cont.) GroupItem Composite

Proxy You want to –delay expensive computations, –use memory only when needed, or –check access before loading an object into memory Proxy –has same interface as Real object –stores subset of attributes –does lazy evaluation

Strategy You want to –use different algorithms depending upon the context –avoid having to change the context or client Strategy –decouples interface from implementation –shields client from implementations –Context is not aware which strategy is being used; Client configures the Context –strategies can be substituted at runtime –example: interface to wired and wireless networks

Strategy (cont.) Client Strategy Concrete StrategyA Concrete StrategyB Context Policy

Bridge You –have several different implementations –need to choose one, possibly at run time Bridge –decouples interface from implementation –shields client from implementations –Abstraction creates and initializes the ConcreteImplementations –Example: stub code, slow code, optimized code

Bridge (cont.) Client Implementor Refined Abstraction Concrete ImplementorA Concrete ImplementorB Abstraction

Design pattern space [from Vlissides]