为什么在kotlin中只能将接口委托给？

我几乎没有看到过类似的问题，但没有人解释过为什么授权仅限于接口

在实践中，大多数时候我们有一些实际上根本没有接口的东西，它是一个只提供一些功能或实现一个抽象类而不实现任何东西的类

是否存在任何基本限制，迫使其仅限于接口，或者我们是否可以期望kotlin在将来拥有不受限制的授权

如果我们想使用组合而不是继承来扩展类的功能，这一点尤其有用

class A {}
class B(val a: A) : A by a {}

---

当您委派介面时，类别仍会实作介面。因此，为了保持一致性，如果您可以委托一个类，它应该以同样的方式工作。即

class A(x: Int) {
  fun foo() = x
}

class B(val a: A) : A by a {}

需要编译到

class B(val a: A) : A {
  override fun foo() = a.foo()
}

但这不起作用：

foo

未打开，无法覆盖

您需要调用

a

的构造函数<代码>B类（val a:a）：a（a.x）也没有帮助：

x

不是

a

的成员

那么

equals

和

hashCode

呢：它们是委托的吗？任何一个决定都会导致奇怪的后果

---

1.所以它不应该试图覆盖它。只有可重写的方法（

open

或

absact

）应自动委派。2.因此，通常需要

B

将构造函数参数传递到

A

。3.Kotlin的作者已经为接口委派做出了这个决定，因为每个接口都隐式地扩展了

Any

，因此具有

等于
、
hashCode
和
toString
。当然，这是一组可能的答案。但是，您不会“使用组合而不是继承来扩展类的功能”；你有一个非常奇怪的组合和继承的组合，在不改变其行为的情况下打开
a
中的方法（例如，因为你发现
C
需要覆盖它）可以改变
B
的行为。如果
a
作为构造函数参数传递给
B
，您将如何以及为什么调用
A
的构造函数？为什么：因为要扩展
A
，您的主构造函数始终必须调用
A
的构造函数。好吧，这正是问题所在。