Strategy Pattern Example

[PaulL]

I have written a paper on the Strategy Pattern (with appendices on Interfaces and the Factory Method Pattern) in the hope that this will be a useful guide to others.

We have published a PDF version of the paper:

StrategyPatternWithLabVIEW

and a zip file that also includes the source and model:

StrategyPatternWithLabVIEW--WithModelAndSource.

You can comment on the paper here, if you like.

Paul

[QFang]

Thank you for making and sharing this. I found the explanations very helpful. My big complaint right now is that I'm incredibly hungry and its only 11am...

Thanks!!

Q

[PaulL]

I'm quite happy to hear it was helpful! Thanks for the feedback!

[Aristos Queue]

My two questions:

1) I have not yet read the paper... is the implementation you give one that you have actually deployed successfully in at least one real application? There have been declarations of "this is a pattern" from folks that have never actually tested their implementation under real-world scenarios and those declarations have turned out false.

2) Assuming it is valid (which I'm expecting given your history of quality), do you mind if we link to it from the patterns page on ni.com?

[PaulL]

1) Yes, although we use the State Pattern -- implemented in exactly the same way -- more often -- in every component, actually, and it is not too much to say that the latter has changed our lives. The pattern itself is a GoF pattern and is the focus of the first chapter in Head First Design Patterns (http://www.amazon.co...35546001&sr=1-1).

2) Of course you may. It is already linked here, actually (https://decibel.ni.c.../docs/DOC-13311), albeit as an add-on.

I hope you do read the paper. I think you will like it.

Paul

[Aristos Queue]

I did finish reading the paper. Good writeup. I have only one request: At several points in the document, you use the term "delegate". I would like you to add comments to specifically disambiguate this pattern from the delegate pattern because the two are nearly identical in implementation. I *think* the major difference between the two is whether the secondary object is supplied from the outside or whether the primary object chooses the secondary itself. It is a fine line distinction that I am not clear on, and I think it is worth touching on.

[PaulL]

Thanks for the feedback. I'll see what I can find. It is worth noting that the GoF book uses the term when discussing the Strategy Pattern (p. 318).

[CRoebuck]

Really good job. I have read several whitepapers written by you in the past and like your style. I'm off to dig aorund the example code so may be back with questions as I'm a hopeless in the kitchen.

[PaulL]

Thanks! I look forward to your questions!

[PaulL]

Hmm... "Delegation Pattern" is not one of the GoF patterns. There is a Wikipedia article (http://en.wikipedia.org/wiki/Delegation_pattern) that gives us simple example without an interface and then many examples with an interface.

This article (http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/delegation.html) gives similar examples, and mentions that "Several other design patterns use delegation - the State, Strategy and Visitor Patterns depend on it." It looks to me like the key idea is that a class assigns a task to some other class that it possesses through Composition. The type of the attribute may actually be abstract so we can vary the specific type. Anyway, that's after a brief read. I haven't looked at this before.

[Daklu]

Hmm... "Delegation Pattern" is not one of the GoF patterns.

I know the "Delegation Pattern" has been mentioned in some early versions of OO pattern documentation on NI's website. In my opinion it is more of a strategy or technique than a pattern. Delegation just means having some other class or component do the work. Patterns give class structures (sometimes with minor variations) to solve fairly specific problems. Delegation is far too broad a topic to be contained in a pattern.

The Best Practices link illustrates the problem. Compare the "Single Inheritance with Delegation" diagram with the "Cat" diagram in the structure section. The class structures are substantially different and there is no explanation as to why they are different. The Cat diagram is an example of dependency injection. (I do this all the time and it is hugely beneficial for unit testing.) I'm not quite sure what to make of the "Single Inheritance..." example. It doesn't work as a general replacement to multiple inheritance like the text implies, though it might be adequate for specific situations. Yes, both examples use delegation to achieve their results, but neither adequately defines delegation.

It looks to me like the key idea is that a class assigns a task to some other class that it possesses through Composition.

This is really the comment that prompted me to respond before I got sidetracked on the response above. Delegating to a composed class is probably the most common way it is used, but I don't think it is necessarily a "key idea" of delegation. There are lots of ways to ask another class to perform a task without using a direct method call.

[eberaud]

Old thread, but I know threads have a long life on LAVA 

 

I just wanted to get clarification about one aspect of this great paper. The factory pattern is used to reduce the linking, and I understand how it does that. But in this example, loading just the dinner simulator class will load all the applicances children and all the cookbehaviors children, so this example doesn't take advantage of the ability of the factory pattern to avoid loading children classes, as explain here for example. Am I correct?

 

The example given in the video uses the Get LV Class Default Value.vi to achieve that.

[PaulL]

You are correct.  The particular implementation of the Factory Method Pattern I show here does include references for all available objects.  This is because:

1) Most of the factories my teams build are for applications that actually use all the object types available.  (This is certainly true for the State Pattern and Command Pattern, not necessarily true for the Strategy Pattern.)  (Of course, I only include the objects that are relevant for the specific application.)

2) We want to maximize performance, so we want the state objects to be in memory.  (Again, this is typically more important for the State Pattern and Command Pattern than the Strategy Pattern).

3) The objects are flyweight or nearly so.  Any external references are simple (one layer deep, to interfaces if applicable).

4) We want to make implementation simple, foolproof, and readable.

 

Reasons to choose an implementation to support some sort of dynamic loading, as the VIShots example does, would be to:

1) Support plug-ins (which may be compelling, but is nontrivial in practice).

2) Avoid loading unneeded objects, as you suggest.

 

It would be simple enough to create a concrete implementation of the CookBehaviorFactory:createCookBehavior() method to use the Get LV Class Default Value.vi instead.

 

Paul

[eberaud]

It would be simple enough to create a concrete implementation of the CookBehaviorFactory:createCookBehavior() method to use the Get LV Class Default Value.vi instead.

 

Yes actually I have been using this exact technique for a while. Thank you for the clarification