[ACCEPTED]-How to format methods with large parameter lists-methods

A large set of parameters like this is often 27 (but not always) an indicator that you could 26 be using an object to represent the parameter 25 set. This is especially true if either:

• There 24 are several methods with similar large parameter 23 sets, that can be replaced with a single 22 method taking a parameter object.

• The method 21 is called create...

So your above code could become 20 (pardon my C++, I'm a Java developer):

class BuildVehicleBooking {
    Long officeId;
    Long start;
    Long end;
    String origin;
    String destination;
    String purpose;             
    String requirements;
    Integer numberOfPassengers;

    Booking createVehicleBooking () throws ServiceException { ... }
}

This 19 is the Builder Pattern. The advantage of this pattern is 18 that you can build up a complex set of parameters 17 in pieces, including multiple variations 16 on how the parameters relate to each other, and 15 even overwriting parameters as new information 14 becomes available, before finally calling 13 the create method at the end.

Another potential 12 advantage is that you could add a verifyParameters method 11 that checked their consistence before you 10 go as far as creating the final object. This is 9 applicable in cases where creating the object 8 involves non-reversible steps, such as writing 7 to a file or database.

Note that, as with 6 all patterns, this doesn't apply in every 5 case and may not apply in yours. If your 4 code is simple enough then this pattern 3 may be over-engineering it. If the code 2 is getting messy, refactoring into this 1 pattern can be a good way to simplify it.

public Booking createVehicleBooking(
    Long officeId, 
    Long start, 
    Long end,
    String origin, 
    String destination, 
    String purpose,                 
    String requirements, 
    Integer numberOfPassengers)

throws ServiceException {
/*..Code..*/
}

0

I'be inclined to go about it with several 17 objects instead of just one.

So it becomes

public Booking createVehicleBooking(Long officeId, DateRange dates, TripDetails trip)

While 16 DateRange and Trip details contain only 15 the relevant portions of the data. Although 14 arguably the dateRange could be part of 13 the trip while Requirements and Number of 12 Passengers could be remoived from TripDetails 11 and made part of the request.

In fact there 10 are several ways to dice the data but I'd 9 have to say breaking your large list into 8 groups of related parameters and building 7 an object for them will allow a clearer 6 programming style and increase possible 5 reuse.

And remember it is always possible 4 to imbed objects in object thus allowing 3 you to have

public Booking createVehicleBooking(BookingParameters parameters)

While BookingParameters Contains 2 TripDetails and DateRange objects as well 1 as the other parameters.

On the calling side I like to simulate named 1 parameters by using comments like this:

booking.createVehicleBooking(
    getOfficeId(),      // Long officeId 
    startVariable,      // Long start 
    42,                 // Long end
    getOrigin(),        // String origin 
    "destination",      // String destination 
    "purpose",          // String purpose       
    "requirements",     // String requirements
    3                   // Integer numberOfPassengers
);

The Google Java Style Guide does not address this directly, but 4 I agree with how they've formatted things 3 in Guava, i.e.

In com.google.common.collect.Collections2.transform:

public static <F, T> Collection<T> transform(
    Collection<F> fromCollection, Function<? super F, T> function) {
  return new TransformedCollection<>(fromCollection, function);
}

In com.google.common.collect.ImmutableRangeMap.toImmutableRangeMap

public static <T, K extends Comparable<? super K>, V>
    Collector<T, ?, ImmutableRangeMap<K, V>> toImmutableRangeMap(
        Function<? super T, Range<K>> keyFunction,
        Function<? super T, ? extends V> valueFunction) {
  return CollectCollectors.toImmutableRangeMap(keyFunction, valueFunction);
}

I think the rules are:

• (Try to keep it on one line if possible)
• Break after the method name and brace
• Indent the parameters one extra level to distinguish them from the body

Personally, I 2 prefer to break after each parameter if 1 I have to break at all, i.e.

public static Foo makeFoo(
    Foo foo,
    Bar bar,
    Baz baz)
      throws FooException {
  f();
}

I like the one param per line approach that 5 you're showing. I find it's very easy to 4 scan it visually and see what's present.

I 3 find that when people use something like 2 Guice you often end up with a large number 1 of params and this makes it easier to read.