In the
CollectingParameter idiom a collection (list, map, etc.) is passed repeatedly as a parameter to a method which adds items to the collection.
Example:
String[] userFiles = ...
List userList = new ArrayList();
for (int i=0; i < userFiles.length; i++) {
addUsersTo(userFiles[i], userList);
}
public void addUsersTo(String userFileName, List userList) {
...
}
Another example is the
TestResult in JUnit.
See also
http://www.industriallogic.com/xp/refactoring/accumulationToCollection.html
A variation on this pattern occurs when the
CollectingParameter is not a collection, but is an object with various properties. As the object is passed around, various actors get and set properties on the
ParameterObject. I think this version of the pattern is generally an
AntiPattern, but may be useful when refactoring from the use of globals. This usage is also related to the old
BidirectionalParameterPattern often used in the
CeeLanguage.
The practice of passing around a collecting parameter can be generalized to using a static closure, instantiating the functions that add to the collection so that they get the collector implicitly, along with a method to return the collection. In other words, an object. Although it can be used beneficially to decouple the state from the method invocation, this idiom is often an
AntiPattern, creating stateful dependencies across methods that should have been grouped into the same object if they truly need such stateful information, and otherwise receiving and acting on state they shouldn't access.
Isn't this pretty much the same as an ouput iterator (e.g.
http://www.sgi.com/tech/stl/OutputIterator.html)? Like java.lang.Appendable for example. --
NiklasMatthies
CategoryCollections