我从未见过如何做到这一点,我会有兴趣看到其他人如何做到这一点。目前我的格式如下:
public Booking createVehicleBooking(Long officeId,
Long start,
Long end,
String origin,
String destination,
String purpose,
String requirements,
Integer numberOfPassengers) throws ServiceException {
/*..Code..*/
}
答案 0 :(得分:16)
像这样的大量参数通常(但不总是)指示您可以使用对象来表示参数集。如果:
,则尤其如此有几种方法具有相似的大型参数集,可以使用参数对象的单个方法替换。
该方法称为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
最终对象。这适用于创建对象涉及不可逆步骤的情况,例如写入文件或数据库。
请注意,与所有模式一样,这并不适用于所有情况,并且可能不适用于您的模式。如果您的代码足够简单,那么这种模式可能会过度设计它。如果代码变得混乱,重构到这种模式可能是简化它的好方法。
答案 1 :(得分:8)
public Booking createVehicleBooking(
Long officeId,
Long start,
Long end,
String origin,
String destination,
String purpose,
String requirements,
Integer numberOfPassengers)
throws ServiceException {
/*..Code..*/
}
答案 2 :(得分:3)
我倾向于使用多个对象而不是一个对象。
所以它变成
public Booking createVehicleBooking(Long officeId, DateRange dates, TripDetails trip)
DateRange和Trip详细信息仅包含数据的相关部分。虽然可以说dateRange可以成为旅行的一部分,但乘客的要求和数量可以从TripDetails中取出并作为请求的一部分。
实际上有几种方法可以对数据进行切块,但我不得不说将大型列表分成相关参数组并为它们构建对象将允许更清晰的编程风格并增加可能的重用。
请记住,始终可以将对象嵌入对象中,从而允许您拥有
public Booking createVehicleBooking(BookingParameters parameters)
BookingParameters包含TripDetails和DateRange对象以及其他参数。
答案 3 :(得分:2)
在调用方面,我喜欢使用以下注释来模拟命名参数:
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
);
答案 4 :(得分:1)
我喜欢你所展示的每行一种方法。我觉得很容易直观地扫描它,看看它的存在。
我发现当人们使用像Guice这样的东西时,你经常会得到大量的参数,这样可以更容易阅读。
答案 5 :(得分:1)
Google Java Style Guide没有直接解决这个问题,但我同意他们在Guava中如何格式化的东西,即
在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);
}
在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();
}