CSE432S

02/20/2006 CSE432S - Nick Beary

CSE432S

Strategy and Template Method Patterns, Single User Protection


Strategy Pattern

“Define a Family of Algorithms, encapsulate each one, and make

them interchangeable.”


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


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.


Strategy – Implementation Issues

• Defining the Strategy and Context interfaces

• Strategies as template parameters

• Making Strategy objects optional


Template Method Pattern

“Define the skeleton of an algorithm in an operation, deferring some steps to

subclasses.”


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?


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.


Template Method – Implementation Issues

• Using C++ access control.

• Minimizing primitive operations

• Naming conventions


Single User Protection

Time for some sweet, sweet Template Method Pattern Action!


Problems

• Write Protection– 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


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!


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.


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…


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.


Read Protection

• Add Templating to reading operations (i.e. streamOut).


Summary

• Strategy 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.

CSE432S

Documents

Transcript of CSE432S