java - number - Cómo formatear métodos con grandes listas de parámetros

string.format android

Question

Nunca he visto una manera de hacer esto bien, me interesaría ver cómo lo hacen los demás. Actualmente lo formato de esta manera:

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

Answer 1

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

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

Answer 2

Un gran conjunto de parámetros como este a menudo (pero no siempre) es un indicador de que podría estar utilizando un objeto para representar el conjunto de parámetros. Esto es especialmente cierto si:

• Existen varios métodos con conjuntos de parámetros grandes similares, que se pueden reemplazar con un único método que toma un objeto de parámetro.

• El método se llama create...

Entonces su código anterior podría convertirse (perdóneme C ++, soy desarrollador de Java):

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

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

Este es el patrón de construcción . La ventaja de este patrón es que puede crear un complejo conjunto de parámetros en piezas, incluidas múltiples variaciones sobre cómo los parámetros se relacionan entre sí, e incluso sobreescribir parámetros a medida que se dispone de nueva información, antes de llamar finalmente al método de create al final. .

Otra ventaja potencial es que puede agregar un método verifyParameters que verifique su consistencia antes de llegar a la creating del objeto final. Esto es aplicable en los casos en que la creación del objeto implica pasos irreversibles, como escribir en un archivo o base de datos.

Tenga en cuenta que, al igual que con todos los patrones, esto no se aplica en todos los casos y es posible que no se aplique en el suyo. Si su código es lo suficientemente simple, este patrón puede estar sobre-ingeniería. Si el código se está volviendo desordenado, la refacturación en este patrón puede ser una buena manera de simplificarlo.

Answer 3

Me inclino a hacerlo con varios objetos en lugar de solo uno.

Entonces se vuelve

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

Mientras que los detalles de DateRange y Trip contienen solo las partes relevantes de los datos. Aunque podría decirse que dateRange podría ser parte del viaje, mientras que los requisitos y el número de pasajeros podrían retirarse de TripDetails y formar parte de la solicitud.

De hecho, hay varias formas de dividir los datos, pero tendría que decir que se divide la lista grande en grupos de parámetros relacionados y crear un objeto para ellos permitirá un estilo de programación más claro y aumentará la posible reutilización.

Y recuerda que siempre es posible incrustar objetos en objetos, lo que te permite tener

public Booking createVehicleBooking(BookingParameters parameters)

While BookingParameters contiene objetos TripDetails y DateRange, así como otros parámetros.

Answer 4

En el lado de las llamadas, me gusta simular parámetros con nombre usando comentarios como este:

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

Me gusta el enfoque de param por línea que estás mostrando. Encuentro que es muy fácil escanear visualmente y ver lo que está presente.

Me parece que cuando la gente usa algo como Guice, a menudo terminas con una gran cantidad de params y esto hace que sea más fácil de leer.

Answer 6

La Guía de estilo de Google Java no aborda esto directamente, pero estoy de acuerdo con la forma en que han formateado las cosas en Guava, es decir,

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

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

Creo que las reglas son:

• (Trate de mantenerlo en una línea si es posible)
• Descanso después del nombre del método y la llave
• Sangra los parámetros un nivel extra para distinguirlos del cuerpo

Personalmente, prefiero romper cada parámetro si tengo que romper, es decir,

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