Parameter Object

Alternative Names

Arguments Object

Context

Intent

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

Problem

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.

Solution

Structure

Dynamics

Implementation Hints

Variations

Origin

James Noble: Arguments And Results

Advantages

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.

Disadvantages

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

Relations to Other Patterns

Generalizations

Specializations

Alternative Patterns

Complementary Patterns

Pattern Collections

Patterns for Arguments and Results
Arguments	Arguments Object	Selector Object	Curried Object
Results	Result Object	Future Object	Lazy Object

Examples

Example 1: Event Args

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

Example 2: CreateProcess

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.

Description Status

Stub

Discussion

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

Principles Wiki

Table of Contents