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