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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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