Interesting. I guess if a strategy is stateless - no member variables that hold data between method calls - it could be a Singleton or Just Create One. The data that it needs to do its job would all be passed as arguments and used in a thread-safe way.
I hope that parameter passing was what "residual state" meant. A quick Google on "residual state" comes up with some electrical stuff and a synonym for "Schizophrenic defect". Probably not what they meant. [ May 09, 2007: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James: I hope that parameter passing was what "residual state" meant.
Most likely. It could refer to the data structure(s) that is (are) left over after you strip away the behaviour - it's that data that the context would have to provide to the "stateless object".
However ultimately I would think that such tactic is self-defeating. If you integrate data of any complexity into a larger pre-existing context object you are sacrificing proper segregation. And if you don't want to sacrifice that you end up more objects - n objects with state vs. 1 stateless object and n "residual state" objects - the only way to reduce the number of simultaneous instances is by making the "residual state" instances transient:
The strategy client creates the "processing context object" and initializes the "input data"
The strategy client invokes the strategy object's method providing this "processing context object".
During processing the strategy object extracts the "input data" from the "processing context object", saves intermediate results to the "processing context object" and finally places the results in the "processing context object".
The strategy client extracts the results from the "processing context object" and finally discards the "processing context object".
Joined: Jan 29, 2003
Singleton or Just Create One would work fine for Functor style strategies. Many of the strategies I've used over the years get what they need as arguments and could be made thread safe easily enough. In fact, here are the (perhaps poorly named) commands in my Wiki. They are not Singletons, but no other code references the implementation classes.
Heh heh, just noticed that my commands are Just Create Two or Three sometimes. I really thought about making a local variable so I could use the same instance two or three times but it blew the looks of the method.