WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.

Slides:



Advertisements
Similar presentations
Welcome to. Who am I? A better way to code Design Patterns ???  What are design patterns?  How many are there?  How do I use them?  When do I use.
Advertisements

WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
18-1 Verifying Object Behavior and Collaboration Role playing – the act of simulating object behavior and collaboration by acting out an object’s behaviors.
Patterns Reusable solutions to common object-oriented programming problems When given a programming problem, re-use an existing solution. Gang of Four.
05/26/2004www.indyjug.net1 Indy Java User’s Group June Knowledge Services, Inc.
(c) 2009 University of California, Irvine – André van der Hoek1June 13, 2015 – 21:42:16 Informatics 122 Software Design II Lecture 8 André van der Hoek.
IEG3080 Tutorial 7 Prepared by Ryan.
Design Patterns CS is not simply about programming
Design Patterns. What are design patterns? A general reusable solution to a commonly occurring problem. A description or template for how to solve a problem.
Design Patterns academy.zariba.com 1. Lecture Content 1.What are Design Patterns? 2.Creational 3.Structural 4.Behavioral 5.Architectural 6.Design Patterns.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
Software Waterfall Life Cycle Requirements Construction Design Testing Delivery and Installation Operations and Maintenance Concept Exploration Prototype.
樣式導向設計 (Pattern-Oriented Design) 課程簡介 Ku-Yaw Chang Assistant Professor, Department of Computer Science and Information Engineering.
05 - Patterns Intro.CSC4071 Design Patterns Designing good and reusable OO software is hard. –Mix of specific + general –Impossible to get it right the.
CSSE 374: Introduction to Gang of Four Design Patterns
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Design Patterns CSCI 5801: Software Engineering. Design Patterns.
DESIGN PATTERNS CSC532 Adv. Topics in Software Engineering Shirin A. Lakhani.
18 April 2005CSci 210 Spring Design Patterns 1 CSci 210.
Software Design Patterns (1) Introduction. patterns do … & do not … Patterns do... provide common vocabulary provide “shorthand” for effectively communicating.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
Object Oriented Software Engineering Chapter 16 and 17 review 2014/06/03.
CSE 403 Lecture 14 Design Patterns. Today’s educational objective Understand the basics of design patterns Be able to distinguish them from design approaches.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
ECE450S – Software Engineering II
Design Patterns CSIS 3701: Advanced Object Oriented Programming.
Introduction to Design Patterns. Questions What is a design pattern? Who needs design patterns? How different are classes and objects in APL compared.
1 Design Patterns Object-Oriented Design. 2 Design Patterns 4Reuse of design knowledge and experience 4Common in many engineering disciplines 4Avoids.
Creational Patterns
What to know for the exam. Smalltalk will be used for questions, but there will not be questions about the grammar. Questions might ask – how particular.
Proxy.
FACTORY METHOD. Design Pattern Space Purpose ScopeCreationalStructuralBehavioral ClassFactory MethodAdapterInterpreter Template Method ObjectAbstract.
Behavioral Patterns CSE301 University of Sunderland Harry R Erwin, PhD.
© 2011 Autodesk Popular Design Patterns and How to Implement Them in.NET Gopinath Taget Senior Developer Consultant.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
Design Patterns. 1 Paradigm4 Concepts 9 Principles23 Patterns.
Design Patterns Introduction
Java Design Patterns Java Design Patterns. What are design patterns? the best solution for a recurring problem a technique for making code more flexible.
CS251 – Software Engineering Lectures 18: Intro to DP Slides by Rick Mercer, Christian Ratliff, Oscar Nierstrasz and others 1 و ابتغ فيما آتاك الله الدار.
Five Minute Design Patterns Doug Marttila Forest and the Trees May 30, 2009 Template Factory Singleton Iterator Adapter Façade Observer Command Strategy.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
7 April 2004CSci 210 Spring Design Patterns 2 CSci 210.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
Design Patterns CSCE 315 – Programming Studio Spring 2013.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
The Object-Oriented Thought Process Chapter 15
Chapter 10 Design Patterns.
樣式導向設計 (Pattern-Oriented Design) 課程簡介
Chapter 5:Design Patterns
MPCS – Advanced java Programming
Design Patterns Lecture part 2.
Introduction to Design Patterns
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2005 Instructor: Patrice Chalin.
WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint 2010.
Software Engineering Lecture 7 - Design Patterns
Design Patterns in Game Design
Informatics 122 Software Design II
CSE 403 Software Design.
Informatics 122 Software Design II
Chapter 8, Design Patterns Singleton
CIS 644 Tues. Nov. 30, 1999 W15A … patterns.
Presentation transcript:

WARNING These slides are not optimized for printing or exam preparation. These are for lecture delivery only. These slides are made for PowerPoint They may not show up well on other PowerPoint versions. You can download PowerPoint 2010 viewer from here.here These slides contain a lot of animations. For optimal results, watch in slideshow mode.

Design (a)

Design (b)

Design (c)

i.Book copies in a library ii.TV drama episodes iii.Video copies in a rental shop

i.Book copies in a library ii.TV drama episodes iii.Video copies in a rental shop

i.Book copies in a library ii.TV drama episodes iii.Video copies in a rental shop  

i.Book copies in a library ii.TV drama episodes iii.Video copies in a rental shop   Recurring tasks in a schedule

i.Book copies in a library ii.TV drama episodes iii.Video copies in a rental shop Recurring tasks in a schedule

Déjà vu: Using patterns to solve recurring problems CS2103/T, Lecture 8, Part 1, [Oct 11, 2013]

Déjà vu: Using patterns to solve recurring problems

experience Déjà vu: Using patterns to solve recurring problems

experience … is what you get when you didn’t get what you wanted.

… is valuable. experience

… is too costly. experience Learning from

experience Learning from Note to self: never volunteer to be the headstand guy

experience Learning from Patterns

Context: Multiple stock items of same TV model Problem: Same data (but not all) shared among stock items of the same model. Solution: Represent TV model and TV stock item as different classes.

Context: Multiple stock items of same TV model Problem: Same data (but not all) shared among stock items of the same model. Solution: Represent TV model and TV stock item as different classes. i.Stock items ii.Book copies in a library iii.TV drama episodes iv.… i.Stock items ii.Book copies in a library iii.TV drama episodes iv.…

Context: Multiple stock items of same TV model Problem: Same data (but not all) shared among stock items of the same model. Solution: Represent TV model and TV stock item as different classes.

Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes.

Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes. > *

Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes. > *

* TVModel TVStockItem * BookTitle BookCopy * Lesson LessonDelivery *

> * TVModel TVStockItem * BookTitle BookCopy * Lesson LessonDelivery *

Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes. Name: Abstraction Occurrence Pattern > *

Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes. Name: Abstraction Occurrence Pattern > * [An elegant solution to a recurring problem]

Name: Abstraction Occurrence Pattern Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes. > * [An elegant solution to a recurring problem]

Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes. Name: Abstraction Occurrence Pattern > *

* Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes. > * Show off ! … for that, I used the Name: Abstraction Occurrence Pattern

Patterns = a high-level vocabulary

Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction.

[A stupid solution to a recurring problem] Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes.

[A stupid solution to a recurring problem] Context: Multiple occurrences of some abstraction Problem: Same data (but not all) shared among occurrences of the same abstraction. Solution: Represent abstraction and occurrences as different classes.

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer

Context: one-and-only-one object, shared among others

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Context: one-and-only-one object, shared among others Problem: how to avoid multiple objects?

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Logic - Logic( ) + getInstance( ) : Logic Solution:

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Logic - theOne : Logic - Logic( ) + getInstance( ) : Logic Solution:

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Logic - theOne : Logic - Logic( ) + getInstance( ) : Logic public static Logic getInstance(){ if (theOne == null) theOne = new Logic(); return theOne; } public static Logic getInstance(){ if (theOne == null) theOne = new Logic(); return theOne; } //somewhere else in the system… Logic m = Logic.getInstance(); //instead of … Logic m = new Logic(); //somewhere else in the system… Logic m = Logic.getInstance(); //instead of … Logic m = new Logic(); Solution:

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Make everything static instead? a)OO ↓ b)Testability ↓ Logic UI LogicStub

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer

Logic - theOne : Logic - Logic( ) + getInstance( ) : Logic public static Logic getInstance(){ if (theOne == null) theOne = new Logic(); return theOne; } public static Logic getInstance(){ if (theOne == null) theOne = new Logic(); return theOne; } //somewhere else in the system… Logic m = Logic.getInstance(); //instead of … Logic m = new Logic(); //somewhere else in the system… Logic m = Logic.getInstance(); //instead of … Logic m = new Logic();

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer How many classes in your project can benefit from this pattern? a. None b. Only 1 c. Only 2 d. Only 3 e. 4 or more single {a|b|c|d|e} e.g. single c single {a|b|c|d|e} e.g. single c 77577

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer

ATD TextUI Logic

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer ATD TextUI MSLogic Logic

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer >

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Edit Sort Delete

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer

Data objects UI elements Create/ edit/ delete/read

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Data objects Create/ edit/ delete/read UI elements VIEW MODEL CONTROLLER

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Data objects Create/ edit/ delete/read UI elements VIEW MODEL CONTROLLER

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer

Paparazzi Celebrity

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Paparazzi Celebrity

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Paparazzi Celebrity

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer Celebrity Paparazzi

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer ListUI Data SummaryUI = Observers AddUI = Observed Celebrity Paparazzi

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer > Observer > Observer ListUI update( ) Data +addViews(Observer) -notifyUIs( ) +addViews(Observer) -notifyUIs( ) * SummaryUI update( ) :Data :Observer = Observers AddUI = Observed

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer > Observer > Observer > update( ) > +add(Observer) -notifyObservers( ) +add(Observer) -notifyObservers( ) * > update( )

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer

Where? → Learning → Applying

Which way do I face? Window or the TV? Darn…

Where? → Learning → Applying

Christopher Alexander

Where? → Learning → Applying Abstraction occurrence  Analysis patterns Singleton  Design patterns MVC  Architectural patterns ….  Testing patterns ….  Project management patterns

Where? → Learning → Applying Abstraction occurrence  Analysis patterns Singleton  Design patterns MVC  Architectural patterns ….  Testing patterns ….  Project management patterns

Where? → Learning → Applying

Creational: Abstract Factory Builder Factory Method Prototype Singleton Creational: Abstract Factory Builder Factory Method Prototype Singleton Structural: Adapter Bridge Composite Decorator Façade Flyweight Proxy Structural: Adapter Bridge Composite Decorator Façade Flyweight Proxy Behavioral : Chain of Responsibility Command Interpreter Template Method Iterator Memento State Visitor Mediator Observer Strategy Behavioral : Chain of Responsibility Command Interpreter Template Method Iterator Memento State Visitor Mediator Observer Strategy GoF patterns

Where? → Learning → Applying

So many patterns, so little time…

Where? → Learning → Applying So many patterns, so little time…

Where? → Learning → Applying So many patterns, so little time…

Where? → Learning → Applying Can apply Singleton in your project?

Where? → Learning → Applying

Part 1 - Déjà vu: Using patterns to solve recurring problems.

1. Abstraction occurrence 2. Singleton 3. Façade 4. Command 5. MVC 6.Observer 7. …… [by next tutorial]

What are the negative consequence of applying the façade pattern? a. Extra code. b. Slower performance. c. Both of the above. d. No negative consequences. negative {a|b|c|d} e.g. negative c negative {a|b|c|d} e.g. negative c 77577