给人看的Kotlin设计模式——原型模式

原型设计模式是一种很简单的设计模式，其实就是通过clone方法去复制一个对象，也就是Java中的Cloneable接口。原型模式是很多语言的特性之一，包括Java和Kotlin。

核心思想：复制代替构造。

Java Cloneable

原型设计模式对应了Effective Java的第十三条谨慎覆盖clone。

Cloneable 接口并没有包含任何方法，那么它到底有什么作用呢？它决定了 Object中受保护的 clone方法实现的行为：如果一个类实现了 Cloneable, Object 的 clone方法就返回该对象的逐域拷贝，否则就会抛出 CloneNotSupportedException 异常。这是接口的一种极端非典型的用法，也不值得仿效 。 通常情况下，实现接口是为了表明类可以为它的客户做些什么 。 然而，对于 Cloneable 接口，它改变了超类中受保护的方法的行为。事实上，实现 Cloneable 接口的类是为了提供一个功能适当的公有的 clone 方法 。
实际上，clone 方法就是另一个构造器；必须确保它不会伤害到原始的对象，并确保正确地创建被克隆对象中的约束条件（invariant）。
简而言之，所有实现了 Cloneable 接口的类都应该覆盖 clone 方法，并且是公有的方法，它的返回类型为类本身。 该方法应该先调用 super.clone 方法，然后修正任何需要修正的域 。 一般情况下，这意味着要拷贝任何包含内部“深层结构”的可变对象，并用指向新对象的引用代替原来指向这些对象的引用 。 虽然，这些内部拷贝操作往往可以通过递归地调用 clone 来完成，但这通常并不是最佳方法 。 如果该类只包含基本类型的域，或者指向不可变对象的引用，那么多半的情况是没有域需要修正 。 这条规则也有例外 。 例如，代表序列号或其他唯一 ID 值的域，不管这些域是基本类型还是不可变的，它们也都需要被修正。
最好提供某些其他的途径来代替对象拷贝。 对象拷贝的更好的办法是提供一个拷贝构造器（copy constructor）或拷贝工厂（copy factory）。拷贝构造器的做法，及其静态工厂方法的变形，都比 Cloneable/clone 方法具有更多的优势：它们不依赖于某一种很有风险的、语言之外的对象创建机制；它们不要求遵守尚未制定好文档的规范；它们不会与 final 域的正常使用发生冲突；它们不会抛出不必要的受检异常；它们不需要进行类型转换。
既然所有的问题都与 Cloneable 接口有关，新的接口就不应该扩展这个接口，新的可扩展的类也不应该实现这个接口。虽然 final 类实现 Cloneable 接 口没有太大的危害，这个应该被视同性能优化，留到少数必要的情况下才使用。 总之，复制功能最好由构造器或者工厂提供 。 这条规则最绝对的例外是数组，最好利用 clone 方法复制数组。

Effective Java关于clone讲了非常多，以上是其核心内容，简单来说就是不应该使用Cloneable接口，而应该考虑使用拷贝构造器（copy constructor）或拷贝工厂（copy factory）来代替，这些是说给谁听的，当然是说给Kotlin听的，于是乎Kotlin在其data class中遵循了这样的建议，提供了方便的copy方法，copy方法其实就相当于一个拷贝工厂，不过，需要注意的是，copy方法实现的是浅拷贝，有些时候需要深拷贝，这就需要我们自己来实现，可以参考也许你需要这个为数据类生成 DeepCopy 方法的库。