Effective-Java-Chapter8-方法

news2025/2/5 15:02:26

https://github.com/clxering/Effective-Java-3rd-edition-Chinese-English-bilingual/blob/dev/Chapter-8/Chapter-8-Introduction.md
在这里插入图片描述

准则一检查参数的有效性

首先对于方法要写详细的文档，例如参数要求，抛出什么异常以源码为例：

又比如，我们可以通过注解的注解标记方法：
对于参数需要严格的校验,例如我们可以使用对象中的工具类

Objects.isNull();
Objects.nonNull();
Objects.requireNonNull()

又比如我们可以使用断言，书中更推荐非公共方法使用断言检查它们的参数：

Assert.notNull();
Assert.isTrue();

准则二在需要时制作防御性副本

这个准则告诉我们如果我们对象中的数据是不可变的，那我们我们一定要保证它一定不可变，不能破坏它。什么意思呢？我们看书中的这个例子：

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(start + " after " + end);
    this.start = start;
    this.end = end;
}

public Date start() {
    return start;
}

public Date end() {
    return end;
}

这个例子乍一看，看不出来有什么问题，感觉它就是安全的，但是其实由于Date是可变的，所以我们可以通过下面的方式改变它：

Date start = new Date();
Date end = new Date();
Period p = new Period(start, end);
// 我们改变了对象中的数据，对象中的数据并不是可变的
end.setYear(78);

于是有了这样的构造函数：

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(this.start + " after " + this.end);
}

然后这样其实还是不安全的因为在get中，我们也可以拿到对象进行修改,于是我们有了这样的写法：

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

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

这样外面的怎么操作都是在副本上操作，绝对不会影响到我们真正的数据，保证了数据的安全性。
注意：

我们没有使用 Date 的 clone 方法来创建防御性副本。因为 Date 不是 final 的，所以不能保证 clone 方法返回一个 java.util.Date 的实例对象：它可以返回一个不受信任子类的实例，这个子类是专门为恶意破坏而设计的。例如，这样的子类可以在创建时在私有静态列表中记录对每个实例的引用，并允许攻击者访问这个列表。这将使攻击者可以自由控制所有实例。为防止此类攻击，对可被不受信任方子类化的参数类型，不要使用 clone 方法进行防御性复制。
我们不总是通过这种方法来保证我们数据的安全性，会影响性能，并且会额外开销内存。

准则三仔细设计方法签名

仔细设计方法名
不要提供过于便利的方法。每种方法都应该各司其职。太多的方法使得类难以学习、使用、记录、测试和维护。对于接口来说更是如此，在接口中，太多的方法使实现者和用户的工作变得复杂。对于类或接口支持的每个操作，请提供一个功能齐全的方法。只有在经常使用时才考虑提供便捷方式。但如果有疑问，就不要提供。
避免长参数列表。设定四个或更少的参数。
对于参数类型，优先选择接口而不是类
双元素枚举类型优于 boolean 参数，除非布尔值的含义在方法名中明确。
这个的意思是用枚举代替传入的布尔型变量。

准则四明智地使用重载

你总是可以为方法提供不同的名称，而不是重载它们。这个不是说不允许重载，而是重载以后可能会有不安全的问题难以发现，如果你确保重载的方法是完全没有歧义的，不会被误用。
不要重载方法来在相同的参数位置上使用不同的函数式接口。
方法可以重载，但并不意味着就应该这样做。通常，最好避免重载具有相同数量参数的多个签名的方法。在某些情况下，特别是涉及构造函数的情况下，可能难以遵循这个建议。在这些情况下，你至少应该避免同一组参数只需经过类型转换就可以被传递给不同的重载方法。如果这是无法避免的，例如，因为要对现有类进行改造以实现新接口，那么应该确保在传递相同的参数时，所有重载的行为都是相同的。如果你做不到这一点，程序员将很难有效地使用重载方法或构造函数，他们将无法理解为什么它不能工作。

准则五明智地使用可变参数

在性能关键的情况下使用可变参数时要小心。每次调用可变参数方法都会导致数组分配和初始化。如果你已经从经验上确定你负担不起这个成本，但是你仍需要可变参数的灵活性，那么有一种模式可以让你鱼与熊掌兼得。假设你已经确定对方法 95% 的调用只需要三个或更少的参数。可以声明该方法的 5 个重载，每个重载 0 到 3 个普通参数，当参数数量超过 3 个时引入可变参数：

public void foo() { }
public void foo(int a1) { }
public void foo(int a1, int a2) { }
public void foo(int a1, int a2, int a3) { }
public void foo(int a1, int a2, int a3, int... rest) { }

最佳实践：
EnumSet

准则六返回空集合或数组，而不是 null

例如返回空集合：

return new ArrayList<>();

也可以引用同一个空列表来节约空间：

Collections.EMPTY_LIST

或者, 这样也是引用同一个列表：

private static final Cheese[] EMPTY_CHEESE_ARRAY = new Cheese[0];
public Cheese[] getCheeses() {
    return cheesesInStock.toArray(EMPTY_CHEESE_ARRAY);
}

准则七明智地的返回 Optional

使用Optional的优势
- 获取默认值的代价很高，除非必要，否则你希望避免这种代价。对于这些情况，Optional 提供了一个方法，该方法接受 Supplier，并仅在必要时调用它。
- Optional 提供了一系列方法如 orElse(), orElseGet(), orElseThrow() 等，这些方法可以优雅地处理 null 值而不需要显式的 if-else 或 null 检查。
- Optional 支持流式编程风格，可以方便地进行链式调用，比如 map() 和 flatMap() 方法可以用来转换或者组合多个 Optional 对象。
永远不要从具备 Optional 返回值的方法返回空值: 它违背了这个功能的设计初衷。这句话显而易见，我们使用Optional是为了避免空指针的问题，但是直接返回空那还需要Optional 做什么呢。
容器类型，包括集合、Map、流、数组和 Optional，不应该封装在 Optional 中。你应该简单的返回一个空的 List，而不是一个空的 Optional<List>。
那么，什么时候应该声明一个方法来返回 Optional 而不是 T 呢？作为规则，你应该声明一个方法来返回 Optional（如果它可能无法返回结果），如果没有返回结果，客户端将不得不执行特殊处理。也就是说，返回 Optional 并不是没有代价的。Optional 对象必须分配和初始化，从 Optional 对象中读取值需要额外的间接操作。这使得 Optional 不适合在某些性能关键的情况下使用。某一特定方法是否属于这一情况只能通过仔细衡量来确定
与返回基本数据类型相比，返回包含包装类的 Optional 类型的代价高得惊人，因为 Optional 类型有两个装箱级别，而不是零。因此，库设计人员认为应该为基本类型 int、long 和 double 提供类似的 Optional。这些可选类型是 OptionalInt、OptionalLong 和 OptionalDouble。它们包含 Optional 上的大多数方法，但不是所有方法。因此，永远不应该返包装类的 Optional，可能除了「次基本数据类型」，如 Boolean、Byte、Character、Short 和 Float 之外。注意这里是说的返回值。
在集合或数组中使用 Optional 作为键、值或元素或这在构造函数中使用几乎都是不合适的。