This is what I consider a "small" pattern.  By that, I mean that it's small in scope rather than "architecture in the large."  Used well, however, it can transform an application.  I'm often amazed at the lack of use in typical moderate-to-large-sized legacy applications.

The basic pattern is to replace the use of primitives or generic classes in a parameter list with an object that holds those parameters.  In Martin Fowler's [[http://www.refactoring.com/catalog/introduceParameterObject.html|example]],
{{{
public class Customer {
  ...
  public Amount amountInvoicedIn(Date start, Date end) {...}
  public Amount amountReceivedIn(Date start, Date end) {...}
  public Amount amountOverdueIn(Date start, Date end) {...}
}
}}}
would become
{{{
public class DateRange {
  public DateRange(Date start, Date end) {...}
  public Date getStart() {...}
  public Date getEnd() {...}
}

public class Customer {
  ...
  public Amount amountInvoicedIn(DateRange dateRange) {...}
  public Amount amountReceivedIn(DateRange dateRange) {...}
  public Amount amountOverdueIn(DateRange dateRange) {...}
}
}}}

Why would you make such a transformation?  There are several forces that might suggest such a direction.

== Simplify the method signature ==

In this example, there are only two dates so the simplification is minimal.  I've seen methods with a parameter list like
{{{
  public void someMethod(String arg1, String arg2, String arg3, boolean b1, boolean b2);
}}}
or worse.  (The names have been changed to protect the innocent.)  It clarifies the situation a lot if you have a cohesive parameter object that holds all these values.  It really simplifies modifications when another value becomes needed.  And, by providing multiple constructors to the parameter object, it identifies appropriate groupings of values when not all are needed.

== Encapsulate special rules ==

You can push some calculations into the parameter object, rather than duplicating them in all of the clients.  Suppose, instead of a simple data object, above, you had a method {{{isInRange(Date date)}}} inside of {{{DateRange}}} to evaluate dates for being inside or outside of that range.  This would eliminate the need for such code within each of the methods that take a {{{DateRange}}}.

What if a date range might be non-contiguous?
{{{
public class NonContiguousDateRange extends DateRange {
   public NonContiguousDateRange(DateRange outerBounds, DateRange excludedRange) {
      this.outerBounds = outerBounds;
      this.excludedRange = excludedRange;
   }
   public boolean isInRange(Date date) {
      return outerBounds.isInRange(date) && !excludedRange.isInRange(date);
   }
}
}}}

== Provide type safety ==
I'll often use a parameter object to encapsulate a single String just to make it clear what that String represents.  This is especially useful when using IDs as an instance indicator.

{{{
...

   public OrderHistory findOrder(String customerId, String orderId)
}}}
might become
{{{
public abstract class StringId {
   public StringId(String idString) {
      this.idString = idString;
   }
   ...
}

public class CustomerId extends StringId {}
public class OrderId extends OrderId {}

...

   public OrderHistory findOrder(CustomerId customerId, OrderId orderId)
}}}

----
See also Martin Fowler's [[http://www.refactoring.com/catalog/introduceParameterObject.html|Introduce Parameter Object]] refactoring.