Strategy Pattern Example
Posted 28 April 2011 - 11:27 PM
We have published a PDF version of the paper:
and a zip file that also includes the source and model:
You can comment on the paper here, if you like.
Posted 27 April 2012 - 04:19 AM
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?
Posted 27 April 2012 - 05:09 PM
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.
Posted 27 April 2012 - 10:45 PM
Posted 08 June 2012 - 10:27 PM
This article (http://best-practice...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.
Posted 13 June 2012 - 07:45 PM
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.
Hmm... "Delegation Pattern" is not one of the GoF patterns.
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.
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.
It looks to me like the key idea is that a class assigns a task to some other class that it possesses through Composition.
Certified LabVIEW Architect
Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.
Yes, the QSM is flexible. So is Jello. That doesn't make it good construction material.
There are two secrets to success:
Secret #1 - Never tell everything you know.