Jak formatować metody z dużymi listami parametrów

Question

Nigdy nie widziałem sposobu, aby to ładnie zrobić, chciałbym zobaczyć, jak inni to robią. Obecnie sformatować go tak:

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

Answer 1

Duży zestaw parametrów, jak to często (ale nie zawsze) to wskaźnik, który może być używany obiekt do reprezentowania zestaw parametrów. Jest to szczególnie prawdziwe, jeśli:

• Istnieje kilka metod o podobnych dużych zestawów parametrów, które mogą zostać zastąpione jednym sposobie podejmowania obiektu parametru.

• Metoda nazywa create...

Więc powyższy kod może stać się (przepraszam mój C++, jestem programistą Java):

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

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

To Wzór Builder . Zaletą tego schematu jest to, że można zbudować złożony zestaw parametrów w częściach, w tym wiele odmian dotyczących wzajemnego powiązania parametrów, a nawet nadpisanie parametrów w miarę pojawiania się nowych informacji, zanim ostatecznie wywołają metodę create na końcu. .

Inną potencjalną zaletą jest to, że można dodać metodę verifyParameters, która sprawdzała ich konsystencję, zanim przejdziemy do ostatecznego obiektu o wartości creating. Ma to zastosowanie w przypadkach, gdy tworzenie obiektu obejmuje nieodwracalne kroki, takie jak zapis do pliku lub bazy danych.

Należy pamiętać, że tak jak w przypadku wszystkich wzorów, nie ma to zastosowania w każdym przypadku i może nie mieć zastosowania w Twoim przypadku. Jeśli twój kod jest wystarczająco prosty, to ten wzorzec może nadużywać go. Jeśli kod jest coraz brudny, refactoring do tego schematu może być dobrym sposobem na jego uproszczenie.

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

Jestem skłonny podchodzić do tego z kilkoma przedmiotami zamiast tylko jednym.

więc staje się to

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

Podczas DATERANGE i szczegóły podróży zawierać jedynie odpowiednie porcje danych. Chociaż prawdopodobnie dataRange może być częścią podróży, podczas gdy wymagania i liczba pasażerów może zostać usunięta z TripDetails i włączyła część żądania.

W rzeczywistości istnieje kilka sposobów na krojenie danych, ale musiałem powiedzieć, że podzielenie dużej listy na grupy powiązanych parametrów i zbudowanie dla nich obiektu pozwoli na wyraźniejszy styl programowania i zwiększy możliwość ponownego wykorzystania.

I pamiętaj, to jest zawsze możliwe imbed obiektów w tym samym obiekcie co pozwala mieć

public Booking createVehicleBooking(BookingParameters parameters) 

Podczas BookingParameters Zawiera TripDetails i DATERANGE obiektów, jak również innych parametrów.

Answer 4

Na stronie wywołującego lubię symulować nazwanych parametrów za pomocą komentarzy tak:

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

Lubię jedno param za podejściem linii, że jesteś pokazano. Uważam, że bardzo łatwo jest go zeskanować wizualnie i zobaczyć, co jest obecne.

Uważam, że gdy ludzie używają czegoś takiego jak Guice, często kończy się to dużą liczbą paramerów, co ułatwia czytanie.

Answer 6

Google Java Style Guide nie odnosi się to bezpośrednio, ale zgadzam się z tym, jak oni sformatowanych rzeczy w guawy, tj

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

W 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 uważam, że obowiązują następujące zasady:

• (Staraj się trzymać go w jednej linii jeśli to możliwe)
• przerwy po nazwie metody i klamra
• wcięcie parametrów jeden dodatkowy poziom, aby odróżnić je od ciała

Osobiście wolę złamać po każdym parametrze, jeśli mam w ogóle przerwać, tj.

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