带有特征的Scala客户机组合与实现抽象类

Question

我在Scala中读到过，通常建议使用特征而不是抽象类来扩展基类。

下面是一个好的设计模式和布局吗？特征就是这样取代抽象的吗？

• 客户端类（具有def功能1)
• Trait1类（重写函数1)
• Trait2类（重写函数1)
• SpecificClient1使用trait1
扩展客户端
• SpecificClient2使用trait2
扩展客户端

Answer 1

我不知道您认为在Scala中应该更喜欢特征而不是抽象类的说法的来源是什么，但有几个理由不这样做：

1. 特性使Java兼容性复杂化。如果您有一个带有伴生对象的trait，那么从Java调用伴生对象上的方法需要奇怪的mytype$.module$.mymethod语法。对于带有伴生对象的抽象类来说，情况并非如此，这些抽象类在JVM上作为一个具有静态和实例方法的类实现。用Java中的具体方法实现Scala特性更令人不快。
2. 将带有实现的方法添加到trait中会破坏二进制兼容性，而将具体方法添加到类中不会。
3. 特性会导致更多字节码和一些与使用转发器方法相关的额外开销。
4. 特征更强大，这是不好的--一般来说，您希望使用功能最弱的抽象来完成工作。如果您不需要它们支持的那种多重继承（而且通常不需要），最好不要访问它。

最后一个原因在我看来是最重要的。在Scala的未来版本中，至少有几个其他问题可能会得到解决，但默认为类将以与良好设计一致的方式约束程序（至少可以说是这样），这种情况仍然存在。如果你决定你真的想要特质提供的力量，它们仍然会存在，但这将是你自己做出的决定，而不是你自己溜走的决定。