Methods Section in Effective Java

1. Check the validity of the parameters

Non-public methods should use assertions to check their parameters, and public methods need to indicate in the Javadoc what exception will be thrown if the parameter violates the limit.

But that's not to say that any restriction on parameters is a good thing, it should be in general and follow the guidelines above.

2. Protective copies must be made when necessary

This section struck me a lot because I never noticed it before when I was writing code.

Take a look at the following piece of code:

public final class Period {
    private final Date start;
    private final Date end;

    public Period(Date start, Date end) {
        if(start.compareTo(end) > 9)
            throw new IllegalArgumentException(
                start + " after " + end);
        this.start = start;
        this.end = end;
    }

    public Date start() {
        return start;
    }

    public Date end() {
        return end;
    }
}

At first glance it seems that Period is immutable, in fact, only start and end cannot point to new references, however, you can pass:

Date start = new Date();
Date end = new Date();
Period p = new Period(start, end);
end.setYear(78);

In this way, start and end in p are changed. If the interface in Period is open to the client, the start and end times can be modified at will, which is obviously not what we want, so we can use protective copy to solve this problem:

public final class Period {
    private final Date start;
    private final Date end;

    public Period(Date start, Date end) {
        this.start = new Date(start.getTime());
        this.end = new Date(end.getTime());
        if(start.compareTo(end) > 9)
            throw new IllegalArgumentException(
                start + " after " + end);
    }
}

Did you find the difference? If the client modifies the returned internal components, the modification is only a copy of the component, and the real start and end cannot be modified, but Period still provides a public interface to access start and end, so protected copy

solve:

    public Date start() {
        return new Date(start.getTime());
    }

    public Date end() {
        return new Date(end.getTime());
    }

As for why the clone() method is not used, it is also written in detail in the book. Date is not a final class, which means that it can be inherited and modified. If someone maliciously inherits Date, the reference will be recorded in a private static list. Seeds are untrustworthy, if taken as

The parameters are passed into the construction method of Period. If the clone() method is used to copy, the untrusted subclass will be copied, or it will make Period very fragile. Here, the java.util.Date class is used to avoid this situation. .

As for internal components such as arrays, arrays with non-zero length must be mutable. Before returning to the client, a protective copy should be made and an immutable view returned to it.

3. Use variadic parameters and overloading carefully, and design method signatures carefully

The principle is: parameters should not be too many, methods should not be too many, method names should be clear and clear, and parameter types should use interfaces instead of classes.

Use overloading and variadic parameters sparingly, as they can obscure the method, and clients often get unexpected results after calling the method. E.g:

System.out.println(Arrays.asList(myArray));

The parameters of the asList() method are variable parameters, which makes the array myArray passed in as the first element of the parameter array as a whole when passing parameters. After wrapping it in List<int[]>, print What comes out is meaningless:

[[I@70dea4e]

4. Return an array or collection of length zero instead of null

I reminded me of this when I used SonarLint, mainly to avoid the tortuous processing method when the client uses it, for example, it must first determine whether it is null or not