1. Strategy and Template Method Patterns, Single User Protection
CSE432S
Strategy and Template Method Patterns, Single User Protection
02/20/2006
CSE432S - Nick Beary

2. Strategy Pattern
“Define a Family of Algorithms, encapsulate each one, and make them interchangeable.”
02/20/2006
CSE432S - Nick Beary

3. Strategy – The General Idea
3 Participants: Strategy, Context, Client (book has Strategy, ConcreteStrategy, Context).
Client interacts with the same interface (Context), but has many options for algorithms (strategies).
Context is the intermediary, but Client must have knowledge of Strategy
02/20/2006
CSE432S - Nick Beary

4. Strategy – Consequences
Families of related algorithms
An alternative to subclassing
Strategies eliminate conditional statements
A choice of implementations
Clients must be aware of different Strategies
Communication overhead between Strategy and Context
Increased number of objects.
02/20/2006
CSE432S - Nick Beary

5. Strategy – Implementation Issues
Defining the Strategy and Context interfaces
Strategies as template parameters
Making Strategy objects optional
02/20/2006
CSE432S - Nick Beary

6. Template Method Pattern
“Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.”
02/20/2006
CSE432S - Nick Beary

7. Template Method – The General Idea
2 participants: AbstractClass and ConcreteClass
Abstract Class defines parts of an algorithm that are invariant, leaves as virtual functions pieces of the algorithm that may or must be defined by Concrete Classes.
The Hollywood Principle – Clever metaphor, or needless pun?
02/20/2006
CSE432S - Nick Beary

8. Template Method – Operations
Concrete Operations
Client class, Concrete Class
Abstract Class
Primitive Operations (abstract operations)
Hook Operations
Key Point: Distinguish operations which may be defined from those that must be defined.
02/20/2006
CSE432S - Nick Beary

9. Template Method – Implementation Issues
Using C++ access control.
Minimizing primitive operations
Naming conventions
02/20/2006
CSE432S - Nick Beary

10. Single User Protection
Time for some sweet, sweet Template Method Pattern Action!
02/20/2006
CSE432S - Nick Beary

11. Problems Write Protection Read Protection Note: File System Level
How do we stop ourselves from making rash decisions about deletion and editing?
Read Protection
How do we keep things from our spouses and/or children? (Vlissides example, not mine)
Note: File System Level
02/20/2006
CSE432S - Nick Beary

12. Write Protection Should prevent any changes to a node (relatively)
Shouldn’t be able to be explicitly deleted, but protection might change at run-time, so can’t use const (C++).
Solution: Protect the destructor!
02/20/2006
CSE432S - Nick Beary

13. Destructor Protection – Who Deletes?
The Node class
A class outside the Node class hierarchy
Creates unnecessary friend status.
A global function
Really no benefit over a static member function.
02/20/2006
CSE432S - Nick Beary

14. Static or no?
Syntax like node->destroy(); and delete this; unsettles some.
Static member doesn’t support modification in subclasses.
Non-virtual member function, employing everybody’s best friend…
02/20/2006
CSE432S - Nick Beary

15. TEMPLATE METHOD!!!
Write a destroy method that takes care of invariant deletion functions, leave details to primitive operations/hooks.
Primitives in this case include protection checking, warning actions, so forth.
02/20/2006
CSE432S - Nick Beary

16. Read Protection Add Templating to reading operations (i.e. streamOut).
02/20/2006
CSE432S - Nick Beary

17. Summary Strategy Pattern Template Method Pattern
1 Context, interchangeable interfaces
Template Method Pattern
Define Algorithm Invariant, leave primitives to subclasses
Single-User Protection
Use Template Method Pattern to apply security protocols, protect you from yourself and prying, ignorant others.
02/20/2006
CSE432S - Nick Beary