Question

文档告诉我们有关open annotation

的信息

类的开放注释与Java的最终注释相反：它允许其他人从此类继承。默认情况下， Kotlin是最终的，与Effective Java, 3rd Edition相对应，第19项：为继承而设计或记录文件，否则将禁止继承。

我的课程

class Foo //I can't inherit it
open class Bar //I can inherit it

然后，默认情况下，最终所有班级的真正动机是什么？任何性能提升？还是仅仅是设计模式？为什么默认情况下禁止open？

Answer 1

对我来说有两个原因：

首先，科特林从函数式编程世界中汲取了许多想法，并尽可能使用不变性来避免所有known problems with mutation。

因此，默认情况下将每个类声明为“ final”（至少对我而言）是相似的。

在运行时不能更改或更改类（使用类似反射的方法），这会使Kotlin编译器的安全检查无效。

因此，如果您要“突变”一个类的默认实现，则必须将其明确标记为打开。

我想到的第二个想法是继承经常被滥用。 here

说明了一些常见陷阱的示例

有一个原则“ Favor composition over inheritance”作为更好设计的准则。因此，默认情况下将每个类都声明为final会迫使开发人员至少停止片刻，并考虑解决问题的替代方法，而不是出于错误的原因而使用继承。

但是只要Kotlin开发人员没有官方声明，我只能给出一个有根据的答案。

Answer 2

Kotlin设计师只是试图确保每个人都遵循良好做法。

正如已经记录的那样，设计人员遵循Joshua Bloch's Effective Java ，其中在类和接口一章中讲到其中的一项原则

设计和记录继承文件，或者禁止继承

它提出了在使用它之前明确记录任何继承行为的想法。

所以，如果有的话，

class Foo

我们（甚至是该代码的非作者）也可以确保class Foo对于任何扩展名都是封闭的，并且没有随机类在使用它，也只需查看其签名即可。相反，Java类不能这样说，除非声明final，否则某些悬挂子类仍然可以扩展它。

另一方面，

open class Foo

仅通过类签名，我们知道该类对继承开放，并且可能会有多个类覆盖其行为。如您所见，继承在此处明确记录。

Answer 3

默认情况下，将类设置为final可以在运行时使用更少的内存。