• Arguments Object

• API Design
• Object-Oriented Design

Group several method parameters in order to keep the number of parameters small and the interface stable.

• Often there are methods which take a large number of input parameters. This makes using them cumbersome and the code less readable. See Long Parameter List and Data Clumps. Sometimes this is also a sign of Primitive Obsession.
• A second problem is the evolution of method signatures. There are circumstances where there is the chance that in the future further parameters will be added without all the users of the method needing the new parameter. Events are an example for that. Normally a change to a method parameter technically requires every caller to change also—independent of whether the caller is logically required to change. This leads to ripple effects and shotgun surgery.

• MIMC: Methods have fewer parameters
• ECV: The method signature is more stable. In case the number of parameters changes, client code is less likely to change. In particular adding a further parameter (i.e. a field to the parameter object) does not require any callers to change if they are not logically required to set the parameter.

• MIMC: An additional class is introduced
• KISS: Calling the method is more complex as the parameter object has to be instantiated

• Selector Object
• Curried Object

A typical usage of this pattern is the grouping of parameter in events. Some events carry large amounts of context data. Furthermore modifying the signature of an event causes large ripple effects as they are typically used on the interface to other subsystems, layers, etc. and there is an unknown and probably large amount of users of the event.

• In .NET there is the class System.EventArgs and its descendants.
• In Java there is java.util.EventObject

The Windows API function CreateProcess is both an example for the problem and (partly) an example for the pattern. Firstly CreateProcess takes ten arguments most of which are even optional. The function is cumbersome to use and hard to read because of the large number of parameters. This is precisely the problem described above.

On the other hand the parameter object pattern is already applied here. The parameters lpProcessAttributes, lpThreadAttributes, and lpStartupInfo are pointers to structures which hold further arguments. This is the procedural equivalent of a parameter object.

Stub

• Parameter Object
• Argument Object

Discuss this wiki article and the pattern on the corresponding talk page.