带有 Traits 的 Scala 客户端组合与实现抽象类 [英] Scala client composition with Traits vs implementing an abstract class

问题描述

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

I have read that with Scala, it is generally advised to use Traits instead of Abstract classes to extend a base class.

以下是好的设计模式和布局吗?这就是 Traits 旨在取代 Abstract 的方式吗?

Is the following a good design pattern and layout? Is this how Traits were intended to replace Abstract?

• 客户端类(带定义函数1)
• trait1 类(覆盖 function1)
• trait2 类(覆盖 function1)
• specificClient1 使用 trait1 扩展客户端
• specificClient2 使用 trait2 扩展客户端

推荐答案

我不知道你的来源是什么，声称你应该更喜欢 Scala 中的抽象类的特征，但有几个原因不 到:

I don't know what your source is for the claim that you should prefer traits over abstract classes in Scala, but there are several reasons not to:

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

1. Traits complicate Java compatibility. If you have a trait with a companion object, calling methods on the companion object from Java requires bizarre MyType$.MODULE$.myMethod syntax. This isn't the case for abstract classes with companion objects, which are implemented on the JVM as a single class with static and instance methods. Implementing a Scala trait with concrete methods in Java is even more unpleasant.
2. Adding a method with an implementation to a trait breaks binary compatibility in a way that adding concrete methods to a class doesn't.
3. Traits result in more bytecode and some additional overhead related to the use of forwarder methods.
4. Traits are more powerful, which is bad—in general you want to use the least powerful abstraction that gets the job done. If you don't need the kind of multiple inheritance they support (and very often you don't), it's better not to have access to it.

最后一个原因在我看来是最重要的.至少有几个其他问题可能会在 Scala 的未来版本中得到修复，但是默认情况下仍然会以类(至少可以说)与良好设计一致的方式约束您的程序.如果你决定你真的真的想要特质提供的力量，它们仍然会在那里，但这将是你做出的决定，而不是你刚刚滑入的东西.

The last reason is by far the most important in my view. At least a couple of the other issues might get fixed in future versions of Scala, but it will remain the case that defaulting to classes will constrain your programs in ways that are (at least arguably) consistent with good design. If you decide you actually really do want the power provided by traits, they'll still be there, but that'll be a decision you make, not something you just slip into.

所以不，在没有其他信息的情况下，我建议使用一个抽象类(最好是密封类)和两个提供实现的具体类.

So no, in the absence of other information, I'd suggest using an abstract class (ideally a sealed one) and two concrete classes that provide implementations.

这篇关于带有 Traits 的 Scala 客户端组合与实现抽象类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！