Как форматировать методы с большими списками параметров

Question

Я никогда не видел способ сделать это красиво, мне было бы интересно посмотреть, как это делают другие В настоящее время я форматирую это так:

public Booking createVehicleBooking(Long officeId, 
                                    Long start, 
                                    Long end,
                                    String origin, 
                                    String destination, 
                                    String purpose,         
                                    String requirements, 
                                    Integer numberOfPassengers) throws ServiceException {
/*..Code..*/
}

Answer 1

Большой набор таких параметров часто (но не всегда) является индикатором того, что вы можете использовать объект для представления набора параметров. Это особенно верно, если либо:

• Существует несколько методов с одинаковыми большими наборами параметров, которые можно заменить одним методом, принимающим объект параметра.

• Метод называется create...

Итак, ваш приведенный выше код может стать (простите мой C ++, я Java-разработчик):

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

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

Это Образец Строителя . Преимущество этого шаблона заключается в том, что вы можете создавать сложный набор параметров по частям, в том числе несколько вариантов того, как параметры связаны друг с другом, и даже перезаписывать параметры по мере появления новой информации, прежде чем, наконец, вызвать метод create в конец.

Еще одним потенциальным преимуществом является то, что вы можете добавить verifyParameters метод, который проверяет их консистенцию, прежде чем идти до creating конечного объекта. Это применимо в случаях, когда создание объекта включает необратимые шаги, такие как запись в файл или базу данных.

Обратите внимание, что, как и для всех шаблонов, это применимо не в каждом случае и не может применяться в вашем случае. Если ваш код достаточно прост, то этот шаблон может быть слишком сложным. Если код запутался, рефакторинг в этот шаблон может быть хорошим способом упростить его.

Answer 2

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

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

Answer 3

Я бы предпочел сделать это с несколькими объектами вместо одного.

Так становится

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

В то время как данные DateRange и Trip содержат только соответствующие части данных. Хотя, возможно, dateRange мог бы быть частью поездки, в то время как Требования и Количество Пассажиров могли быть сняты с TripDetails и выполнены как часть запроса.

На самом деле есть несколько способов нарезать данные кубиками, но я бы сказал, что разбив ваш большой список на группы связанных параметров, и построение объекта для них позволит более четко программировать стиль и увеличить возможное повторное использование.

И помните, что всегда возможно вставить объекты в объект, что позволяет вам иметь

public Booking createVehicleBooking(BookingParameters parameters)

Хотя BookingParameters Содержит объекты TripDetails и DateRange, а также другие параметры.

Answer 4

На вызывающей стороне мне нравится имитировать именованные параметры, используя такие комментарии:

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
);

Answer 5

Руководство по стилю Google Java не решает эту проблему напрямую, но я согласен с тем, как они отформатировали вещи в Гуаве, т.е.

В 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);
}

Я думаю, что правила таковы:

• (по возможности старайтесь держать его на одной строке)
• Перерыв после имени метода и скобки
• Отступы параметров на один дополнительный уровень, чтобы отличить их от тела

Лично я предпочитаю разбивать после каждого параметра, если мне вообще нужно разбивать, т.е.

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

Answer 6

Мне нравится подход «один параметр на строку», который вы показываете. Я считаю, что это очень легко сканировать визуально и посмотреть, что присутствует.

Я считаю, что когда люди используют что-то вроде Guice, вы часто получаете большое количество параметров, и это облегчает чтение.