====== Parameter Object ======

===== Alternative Names =====

  * Arguments Object

===== Context =====

  * [[contexts:API Design]]
  * [[contexts:Object-Oriented Design]]

===== 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 [[anti-patterns:Long Parameter List]] and [[anti-patterns:Data Clumps]]. Sometimes this is also a sign of [[anti-patterns: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. [[glossary: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 [[glossary:ripple effects]] and [[glossary:shotgun surgery]].

===== Solution =====


==== Structure ====

==== Dynamics ====

==== Implementation Hints ====

==== Variations ====


===== Origin =====

{{page>resources:Arguments and Results#reference}}


===== Advantages =====

  * [[principles:More Is More Complex|MIMC]]: Methods have fewer parameters
  * [[principles:Encapsulate the Concept that Varies|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 =====

  * [[principles:More Is More Complex|MIMC]]: An additional class is introduced
  * [[principles:Keep It Simple Stupid|KISS]]: Calling the method is more complex as the parameter object has to be instantiated 


===== Relations to Other Patterns =====

==== Generalizations ====

==== Specializations ====

  * [[Selector Object]]
  * [[Curried Object]]

==== Alternative Patterns ====

==== Complementary Patterns ====

==== Pattern Collections ====
{{page>collections:Patterns for Arguments and Results#Box}}


===== Examples =====

==== Example 1: Event Args ====

A typical usage of this pattern is the grouping of parameter in [[glossary: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 [[http://msdn.microsoft.com/de-de/library/vstudio/system.eventargs.aspx|System.EventArgs]] and its descendants.
  * In Java there is [[http://docs.oracle.com/javase/7/docs/api/java/util/EventObject.html|java.util.EventObject]]

==== Example 2: CreateProcess====

The Windows API function [[http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx|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 =====
/* Choose one of the following and comment out the rest: */
[[wiki:Stub]]
/*[[wiki:Incomplete]]*/
/*[[wiki:Complete]]*/


===== Further Reading =====

  * [[wiki>Parameter Object]]
  * [[wiki>Argument Object]]


===== Discussion =====

Discuss this wiki article and the pattern on the corresponding [[talk:patterns:Parameter Object|talk page]].