15
1 GoF Template Method (pp. 325- 330) GoF Strategy (pp. 315-323) PH Single User Protection (pp. 34-40) Presentation by Julie Betlach 6/08/2009
1
GoF Template Method (pp. 325-330)GoF Strategy (pp. 315-323)
PH Single User Protection (pp. 34-40)
Presentation by Julie Betlach6/08/2009
2
Template Method Pattern - Intent / Applicability
• Intent– Define the skeleton of an algorithm, deferring some steps to
subclasses. – Template Method lets subclasses redefine certain steps of an
algorithm, without changing the algorithm’s structure.
• Applicability – Use Template Method Pattern…– To implement the invariant part of an algorithm, and leave it up
to subclasses to implement the part that can vary.– When common code in subclasses should be factored and
localized in a common base class to avoid code duplication.– To control extensions to subclasses. (Hook operations)
GoF Template Method (pp. 325-330)
3
Template Method Pattern - Participants
• AbstractClass– Defines abstract primitive operations that concrete subclasses
define to implement steps of an algorithm.– Implements a template method defining the skeleton of an
algorithm. It calls primitive operations as well as other operations in the AbstractClass (or other classes).
GoF Template Method (pp. 325-330)
• ConcreteClass– Implements primitive
operations to carry out subclass-specific steps of the algorithm.
Note: Some concrete AbstractClass methods can also be defined.
Hollywood Principle – “Don’t call us, we’ll call you.” => Parent class calls operations of subclass.
4
Template Method Pattern - Participants
void Application::OpenDocument (const char* name) {
if (!CanOpenDocument(name)) {
return;
}
Document* doc = DoCreateDocument();
if (doc) {
_docs->AddDocument(doc);
AboutToOpenDocument(doc);
doc->Open();
doc->DoRead();
}
}
GoF Template Method (pp. 325-330)
Basic Algorithm is the same for all documents.
Template Method
PrimitiveOperation
Concrete AbstractClass Operation
5
Template Method Pattern - Implementation
void Application::OpenDocument (const char* name) {
if (!CanOpenDocument(name)) {
return;
}
Document* doc = DoCreateDocument();
if (doc) {
_docs->AddDocument(doc);
AboutToOpenDocument(doc);
doc->Open();
doc->DoRead();
}
}
GoF Template Method (pp. 325-330)
Primitive Operation that has a default behavior in abstract class = Hook operation.
Template Method – Don’t want this to be overridden, so make it nonvirtual member function.
Primitive Operations that must be overridden (make these pure virtual in abstract class).Concrete
AbstractClass Operation
Naming Convention suggestion is confusing.Are DoCreateDocument and DoRead from the example called Template Methods? I think book should have said that MacApp framework prefixes primitive operation names with “Do”.
6
Related Patterns
• Factory Methods – Are often called by template methods. Example: Factory Method DoCreateDocument is called by Template Method OpenDocument.
• Strategy – Template Methods use inheritance to vary part of an algorithm. Strategies use delegation to vary the entire algorithm.
GoF Template Method (pp. 325-330)
7
Strategy Pattern - Intent / Applicability
• Intent– Define a family of algorithms, encapsulate each one, and make
them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
• Applicability – Use Strategy Pattern when…– Many related classes differ only in their behavior.– You need different variants of an algorithm. For example,
defining different algorithms based on space-time tradeoffs.– An algorithm uses data that a client shouldn’t know about.– A class defines many behaviors, and these appear as multiple
conditional statements in its operations. Instead, move related conditional branches into their own Strategy class.
GoF Strategy (pp. 315-323)
8
Strategy Pattern - Participants• Strategy
– Declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy.
• ConcreteStrategy– Implements the algorithm using the Strategy interface.
• Context– Is configured with a ConcreteStrategy object
– Maintains a reference to a Strategy object
– May define an interface that lets Strategy access its data.
GoF Strategy (pp. 315-323)
Picture & Example from: http://www.dofactory.com/Patterns/PatternStrategy.aspx
9
Strategy Pattern - Participantshttp://www.dofactory.com/Patterns/PatternStrategy.aspx
Show code in RealWorld Example• Strategy
– SortStrategy
• ConcreteStrategy– QuickSort– ShellSort– MergeSort
• Context– SortedList
GoF Strategy (pp. 315-323)
Picture & Example from: http://www.dofactory.com/Patterns/PatternStrategy.aspx
10
Strategy Pattern – Consequences• Good Consequences
– Good for families of related algorithms. Inheritance can help factor out common functionality of algorithms.– Alternative to subclassing which allows the developer to vary the algorithm independent of its context.– Strategies eliminate conditional statements.– Provide different implementations of the same behavior. Example: Sorting is goal, but many ways to sort.
• Drawbacks– Clients must be aware of different strategies.– Communication overhead between Strategy and Context – some concrete strategies may not need all the parameters
passed into them.– Increased number of objects. See Flyweight pattern for an approach to solve this.
GoF Strategy (pp. 315-323)
11
Related Patterns
• Flyweight – Strategy objects often make good flyweights.
GoF Strategy (pp. 315-323)
12
Single User Protection
• Read Protection (do not reveal contents)– Disallow streamOut– Disallow getChild (makes sense if you consider
example of hiding the family tree information of a person, where getChild returns the name of the person’s descendents.)
• Write Protection (protect both attributes and structure)– Disallow streamIn, setName, adopt, orphan– Treat setProtection carefully (explained in multi-user
section)
PH Single User Protection (pp. 34-40)
13
Single User Protection
• Write Protection (continued)– Prevent deletion
• Can’t declare a node as a const in order to get compiler to check this for us, because a node’s protection may change at runtime.
• Instead, we can Protect the Destructor by putting it in the Protected section.
– Don’t want to make it private because that wouldn’t let subclasses extend the destructor to delete their children or any other objects that they aggregate.
• We want a static member function (makes syntax nicer) and we want the subclasses to be able to extend the definition.
PH Single User Protection (pp. 34-40)
14
Single User Protection
• Solution = Destroy() will be a Template Method!
PH Single User Protection (pp. 34-40)
class Node {public: static void destroy (Node*); // template methodprotected: virtual ~Node(); virtual bool isWriteable() = 0; // primitive operation virtual void doWarning() = 0; // primitive operation};
void Node::destroy (Node* node) { if (node->isWriteable()) { delete node; } else { node->doWarning(undeletableWarning); }}
Technically, isWriteable should start with “do” to be clear it is a primitive operation.
Because destroy is static, it can’t call Node operations directly.But it doesn’t need to because it calls primitive operations in the subclasses.
15
Single User ProtectionPH Single User Protection (pp. 34-40)
class Node {public: static void destroy (Node*); // static template method void streamOut (ostream& out); // non-static template method (also not virtual)protected: virtual ~Node(); virtual bool isWriteable() = 0; // primitive operation virtual bool isReadable() = 0; // primitive operation virtual void doWarning() = 0; // primitive operation virtual void doStreamOut() = 0; // primitive operation};
void Node::streamOut (ostream& out) { if (isReadable()) { doStreamOut(); } else { doWarning(unreadableWarning); }}
However, if we define another template method which is not static, it is allowed to call Node functions, so it doesn’t need the node passed in.
