table of Contents
Article 38 Check the validity of parameters
Article 39 Protective copying when necessary
Article 40 Carefully design method signatures
Article 41 Use overloads with caution
Article 42 Use variable parameters with caution
Article 43 returns a zero-length array or collection, not null
Article 44 Write documentation notes for all exported API elements
Focus: Usability, robustness, flexibility
Article 38 Check the validity of parameters
When writing methods or constructors, you should consider the limitations of parameters and explicitly check
Article 39 Protective copying when necessary
If the class has mutable components obtained from the client or returned to the client, in order to maintain immutability, it is necessary to make a protective copy.
Otherwise, it is stated in the document that this component cannot be modified.
For example:
public final class Period {
private final Date start;
private final Date end;
public Period(Date start, Date end) {
if (start.compareTo(end) > 0) {
throw new IllegalArgumentException(strat + "after" + end);
}
this.start = start;
this.end = end;
}
public Date start() {
return start;
}
public Date end() {
return end;
}
}
Period represents an immutable period of time.
However, Period is not immutable! ! ! Because Date is variable.
Date start = new Date();
Date end = new Date();
Period p = new Period(strat, end);
end.setYear(78);//因为Date是可变的，导致p被修改了Solution:
public Period(Date start, Date end) {
//先进行保护性拷贝，然后再对拷贝后的进行检查
this.start = new Date(start.getTime()); //使用保护性拷贝
this.end = new Date(end.getTime()); //使用保护性拷贝
if (this.start.compareTo(this.end) > 0) {
throw new IllegalArgumentException(strat + "after" + end);
}
}
Period can still be changed.
Date start = new Date();
Date end = new Date();
Period p = new Period(strat, end);
p.end().setYear(78);//因为Date是可变的，导致p被修改了Solution:
public Date start() {
return new Date(start.getTime());
}
public Date end() {
return new Date(end.getTime());
}
Article 40 Carefully design method signatures
1. Avoid long parameter lists. 4 parameters, or less.
Don't define long parameter sequences of the same type, it is easy to accidentally mistake the parameter order.
How to shorten the long parameter list?
1) Split into multiple methods
2) Create an auxiliary class to save the grouping of parameters.
3) Adopt Builder mode. This method is especially useful when the method has multiple parameters, and some of them are optional!
2. For parameter types, interfaces are preferred over classes.
3. For the boolean type, the enumeration type of two elements is preferred
Article 41 Use overloads with caution
Why use overloading with caution?
Because under special circumstances (type conversion, automatic boxing and unboxing, etc.), it is difficult to determine which overloaded method will be called.
Suggest
1) For multiple methods with the same number of parameters, overloading should be avoided as much as possible.
2) To avoid this situation: the same set of parameters can be passed to different overloaded methods only after type conversion.
举例：m(List<?> s)，m(Set<?> s)，m(Collection<?> s)。
Article 42 Use variable parameters with caution
When performance is important, use variable parameters with care. Each call of a variable parameter will result in an array allocation and initialization.
How to improve? When it is determined that 95% of calls have 3 or fewer parameters, define 5 overloaded methods.
m()
m(int a)
m(int a, int b)
m(int a, int b, int c)
m(int a, int b, int c, int ....rest)
Article 43 returns a zero-length array or collection, not null
For methods whose return type is an array or collection, it returns a zero-length array or collection instead of returning null.