In the Collecting Parameter 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 Test Result in JUnit.
See also www.industriallogic.com 
A variation on this pattern occurs when the Collecting Parameter 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 Parameter Object. I think this version of the pattern is generally an Anti Pattern, but may be useful when refactoring from the use of globals. This usage is also related to the old Bidirectional Parameter Pattern often used in the Cee Language.
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 Anti Pattern, 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. www.sgi.com )? Like java.lang.Appendable for example. -- Niklas Matthies
See original on c2.com