当前位置：文江博客话题详情

为什么人们在 Scala 中的另一个对象中定义类、特征、对象？

发布于 2024-10-12 10:39:27 字数 633 浏览 6 评论 0原文

好的，我会解释为什么我问这个问题。这几天我开始阅读Lift 2.2源代码。如果您之前碰巧读过 lift 源代码，那就太好了。

在Lift中，我发现定义内部类和内部特征被大量使用。

对象 Menu 有 2 个内部特征和 4 个内部类。对象 Loc 有 18 个内部类、5 个内部特征、7 个内部对象。

像这样写的代码有很多。我想知道作者为什么要这样写。

是不是因为是作者的个人品味或强大的使用语言功能？
这种有什么权衡吗的用途？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

仅一夜美梦 2024-10-19 10:39:27

在 2.8 之前，您必须在包和对象之间进行选择。包的问题是它们不能单独包含方法或值。所以你必须把所有这些都放在另一个对象中，这可能会很尴尬。观察：

object Encrypt {
  private val magicConstant = 0x12345678
  def encryptInt(i: Int) = i ^ magicConstant
  class EncryptIterator(ii: Iterator[Int]) extends Iterator[Int] {
    def hasNext = ii.hasNext
    def next = encryptInt(ii.next)
  }
}

现在您可以导入 Encrypt._ 并获得对 encryptInt 方法以及 EncryptIterator 类的访问权限。便利！

相比之下，

package encrypt {
  object Encrypt {
    private[encrypt] val magicConstant = 0x12345678
    def encryptInt(i: Int) = i ^ magicConstant
  }
  class EncryptIterator(ii: Iterator[Int]) extends Iterator[Int] {
    def hasNext = ii.hasNext
    def next = Encrypt.encryptInt(ii.next)
  }
}

这并不是一个巨大差异，但它使用户同时导入 encrypt._ 和 encrypt.Encrypt._ 或者必须保留一遍又一遍地编写Encrypt.encryptInt。为什么不像第一个模式那样只使用一个对象呢？（实际上没有性能损失，因为嵌套类实际上并不是底层的 Java 内部类；就 JVM 所知，它们只是常规类，但有一些奇特的名称告诉您它们是嵌套的。）

在 2.8 中，你可以鱼与熊掌兼得：将这个东西称为包对象，编译器会为你重写代码，所以它实际上看起来就像第二个例子（除了对象 Encrypt实际上在内部称为package），但在命名空间方面的行为类似于第一个示例——vals 和 defs 就在那里，不需要额外的导入。

因此，在 2.8 之前开始的项目通常使用对象来封装大量内容，就像它们是一个包一样。 2.8 之后，主要动机之一已被删除。（但要明确的是，使用对象仍然没有坏处；更多的是它在概念上具有误导性，而不是对性能或其他方面产生负面影响。）

（PS 请不要尝试以这种方式实际加密任何内容除了作为例子或笑话！）

Before 2.8, you had to choose between packages and objects. The problem with packages is that they cannot contain methods or vals on their own. So you have to put all those inside another object, which can get awkward. Observe:

object Encrypt {
  private val magicConstant = 0x12345678
  def encryptInt(i: Int) = i ^ magicConstant
  class EncryptIterator(ii: Iterator[Int]) extends Iterator[Int] {
    def hasNext = ii.hasNext
    def next = encryptInt(ii.next)
  }
}

Now you can import Encrypt._ and gain access to the method encryptInt as well as the class EncryptIterator. Handy!

In contrast,

package encrypt {
  object Encrypt {
    private[encrypt] val magicConstant = 0x12345678
    def encryptInt(i: Int) = i ^ magicConstant
  }
  class EncryptIterator(ii: Iterator[Int]) extends Iterator[Int] {
    def hasNext = ii.hasNext
    def next = Encrypt.encryptInt(ii.next)
  }
}

It's not a huge difference, but it makes the user import both encrypt._ and encrypt.Encrypt._ or have to keep writing Encrypt.encryptInt over and over. Why not just use an object instead, as in the first pattern? (There's really no performance penalty, since nested classes aren't actually Java inner classes under the hood; they're just regular classes as far as the JVM knows, but with fancy names that tell you that they're nested.)

In 2.8, you can have your cake and eat it too: call the thing a package object, and the compiler will rewrite the code for you so it actually looks like the second example under the hood (except the object Encrypt is actually called package internally), but behaves like the first example in terms of namespace--the vals and defs are right there without needing an extra import.

Thus, projects that were started pre-2.8 often use objects to enclose lots of stuff as if they were a package. Post-2.8, one of the main motivations has been removed. (But just to be clear, using an object still doesn't hurt; it's more that it's conceptually misleading than that it has a negative impact on performance or whatnot.)

(P.S. Please, please don't try to actually encrypt anything that way except as an example or a joke!)

回复收藏 0 原文