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