为什么没有默认的clone（）在Java

Question

Java中的Cloneable本质上是不可靠的。具体地说，我对接口的最大问题是，它需要一个不定义方法本身的方法行为。因此，如果遍历一个Cloneable列表，您必须使用反射来访问它定义的行为。然而，在Java8中，我们现在有了默认方法，现在我问为什么在Cloneable中没有默认的clone（）方法。

我理解为什么接口不能默认对象方法，但是，这是一个明确的设计决定，所以可以做出例外。

我有点想弃用对象。克隆（）并将其内部代码更改为类似以下内容：

if(this instanceof Cloneable) {
    return ((Cloneable) this).clone();
}
else {
    throw new CloneNotSupportedException();
}

然后继续使用使clone（）作为Clonable中的默认方法的魔法。这并不能真正解决clone（）仍然很容易被错误地实现的问题，但这本身就是另一个讨论。

据我所知，这种变化是完全向后兼容的：

1. 当前覆盖clone（）但未实现Cloneable的类（为什么？！）在技术上仍然可以（即使功能上不可能，但这与以前没有什么不同）

更不用说这将解决Cloneable所面临的巨大问题。虽然它很乏味，而且很容易错误地实现，但它将解决一个巨大的面向对象接口问题。

我能看到的唯一问题是那些实现Clonable的人没有义务重写clone（），但这与以前没有什么不同。

这是否已经在内部讨论过，但从未取得成果？若然，原因为何？如果是因为接口不能默认对象方法的原因，那么在这种情况下做一个例外是否有意义，因为所有继承Cloneable的对象都需要clone（）？

Answer 1

我的经验可能远不是主流，但我使用clone（）并支持当前的Cloneable设计。也许最好将其作为注释，但是Cloneable早在注释出现之前就出现了。我的观点是，Cloneable是一个低级的东西，任何人都不应该做类似于obj instanceof Cloneable的事情。如果在某些业务逻辑中使用Cloneable，最好声明自己的接口或抽象类，将clone（）公开，并在所有业务逻辑对象中实现它。有时您可能不想公开clone（），而是创建自己的方法，在内部使用clone（）。

例如，假设您有一个命名对象的层次结构，其中名称在构建后不能更改，但您希望允许用新名称克隆它们。您可以创建一些像这样的抽象类：

public abstract class NamedObject implements Cloneable {
    private String name;

    protected NamedObject(String name) {
        this.name = name;
    }

    public final String getName() {
        return name;
    }

    public NamedObject clone(String newName) {
        try {
            NamedObject clone = (NamedObject)super.clone();
            clone.name = newName;
            return clone;
        }
        catch(CloneNotSupportedException ex) {
            throw new AssertionError();
        }
    }
}

在这里，即使您实现了Clonable，您也希望使用clone（），但不希望将其公开。相反，您提供了另一个允许克隆另一个名称的方法。因此，在Clonable中使用公共clone（）会不必要地污染类的公共接口。

我使用Cloneable的另一个例子是拆分器的实现。trySplit（）。请参阅简单拆分器的实现，它返回给定数量的常量对象。它有四个专门化（对象、整数、长整数和双整数），但由于clone（）我只能在超类中实现一次trySplit（）。同样，我不想公开clone（），我只想自己使用它。

总之，在Cloneable接口中没有clone（）方法实际上更灵活，因为它允许我决定是否将其公开。

Answer 2

你的问题有点宽泛，更像是讨论，但我可以就此事提供一些信息。

在有效Java™中，约书亚·布洛赫详细介绍了这种情况。他以Clonable后面的一点历史开始

Cloneable接口的目的是作为对象的mixin接口来公布它们允许克隆。不幸的是，它未能达到这一目的。它的主要缺陷是缺少克隆方法，并且对象的克隆方法受到保护。如果不诉诸反射，就不能仅仅因为对象实现了Cloneable而对其调用clone方法。

并继续进行推理

[克隆]确定Object受保护克隆实现的行为：如果一个类实现了克隆，Object的克隆方法返回该对象的逐字段副本...这是一种非常不典型的接口使用，不需要模拟。通常，实现接口说明了类可以为其客户端做些什么。在克隆的情况下，它修改超类上受保护方法的行为。

和

如果实现可克隆接口要对一个类产生任何影响，那么该类及其所有超类必须遵守一个相当复杂、不可执行且文档稀少的协议。由此产生的机制是语言外的：它创建一个对象而不调用构造函数。

这里有很多细节，但是要注意一个问题：

克隆体系结构与引用可变对象的final字段的正常使用不兼容。

我认为这足以说明为什么不在接口中使用default方法进行克隆。正确地实施它将是极其复杂的。