Comment formater des méthodes avec de grandes listes de paramètres

Question

Je n'ai jamais vu un moyen de le faire bien, je serais intéressé de voir comment les autres le font. Actuellement, je formate comme ceci:

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

Answer 1

Un grand nombre de paramètres comme celui-ci est souvent (mais pas toujours) un indicateur que vous pourriez utiliser un objet pour représenter l'ensemble des paramètres. Cela est particulièrement vrai si:

• Il existe plusieurs méthodes avec de grands ensembles de paramètres similaires, qui peuvent être remplacés par une seule méthode prenant un objet de paramètre.

• La méthode est appelée create...

donc votre code ci-dessus pourrait devenir (pardonnez mon C++, je suis un développeur Java):

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

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

C'est le modèle Builder . L'avantage de ce modèle est que vous pouvez construire un ensemble complexe de paramètres, y compris de multiples variations sur la façon dont les paramètres sont reliés entre eux, et même écraser les paramètres lorsque de nouvelles informations deviennent disponibles avant d'appeler finalement la méthode create .

Un autre avantage potentiel est que vous pouvez ajouter une méthode verifyParameters qui vérifie leur consistance avant d'aller jusqu'à creating l'objet final. Ceci est applicable dans les cas où la création de l'objet implique des étapes non réversibles, telles que l'écriture dans un fichier ou une base de données. Notez que, comme pour tous les modèles, cela ne s'applique pas dans tous les cas et peut ne pas s'appliquer dans les vôtres. Si votre code est assez simple, il se peut que ce modèle soit trop complexe. Si le code devient en désordre, refactoring dans ce modèle peut être un bon moyen de le simplifier.

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

Je suis enclin à le faire avec plusieurs objets au lieu d'un seul.

Ainsi, il devient

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

Alors que DateRange et les détails de voyage ne contiennent que les parties pertinentes des données. Bien que sans doute le dateRange pourrait faire partie du voyage tandis que les exigences et le nombre de passagers pourraient être retirés de TripDetails et fait partie de la demande. En fait, il existe plusieurs façons de découper les données, mais je dois dire que le découpage de votre grande liste en groupes de paramètres associés et la construction d'un objet pour eux permettront un style de programmation plus clair et augmenteront la réutilisation possible.

Et rappelez-vous, il est toujours possible d'incruster des objets en objets vous permettant ainsi d'avoir

public Booking createVehicleBooking(BookingParameters parameters) 

Bien que BookingParameters Contient TripDetails et objets DateRange ainsi que les autres paramètres.

Answer 4

Du côté appelant j'aime simuler des paramètres nommés en utilisant des commentaires comme celui-ci:

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

J'aime une approche par param ligne que vous montrez. Je trouve qu'il est très facile de le scanner visuellement et de voir ce qui est présent.

Je trouve que lorsque les gens utilisent quelque chose comme Guice, vous vous retrouvez souvent avec un grand nombre de paramètres, ce qui facilite la lecture.

Answer 6

Le Google Java Style Guide ne répond pas directement, mais je suis d'accord avec la façon dont ils ont mis en forme des choses dans Goyave, à savoir

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

Dans 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 pense que les règles sont:

• (Essayez de le garder sur une ligne si possible)
• Pause après le nom de la méthode et croisillon
• Indentation les paramètres d'un niveau supplémentaire pour les distinguer du corps

Personnellement, je préfère briser après chaque paramètre si je dois rompre du tout, par exemple

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