Scala - 将代码拆分为特征、类、对象时的设计选择

Question

我的代码总是一团糟，我认为我缺乏一些基础知识。当我尝试将功能拆分为特征和对象时，我不太确定最佳实践是什么……或者为什么选择一种形式而不是另一种形式。我使用了以下三种方法，但我不一定清楚为什么要选择其中一种。任何人都可以帮助我考虑构建这些依赖项的不同方法吗？

选项 1 - 最简单的方法，模块化，根据需要调用......老实说，我倾向于走这条路线以保持简单......尽管它通常需要将大量参数传递给比这个简单示例更复杂的方法，所以它不是很优雅。

object A {
  def run(x: T): Unit = ??? // do stuff with x
}

object Main {
  val x: T = ???
  def main(args: Array[String]): Unit = {
    A.run(x)
  }
}

选项 2 - 历史上我主要在我的代码中使用这种方法......如果特征 A 中的代码是为对象 Main 设计的，我只是将其拆分以使事情更容易理解......这在逻辑上对我来说是有意义的.它还最小化了传递给函数的参数，感觉更干净。但是......这使得代码更难重用。如果从现在起六个月后，由于我以一种出乎意料的方式扩展了一个项目，所以我需要在对象 Main 以外的某个地方使用 trait A 中的一个函数，这将变得很困难。

trait A {
  def x: T
  def run: Unit = ??? // do stuff with x
}

object Main extends A {
  val x: T = ???

  def main(args: Array[String]): Unit = {
    run
  }
}

选项 3 - 我认为这在混合大量依赖项时最好？老实说，我不太确定。同样，随着项目功能的扩展，这变得非常难以重用。可能是由于我的设计选择不佳。

trait A {
  this: Main =>
  val runner: Runner
  class Runner(x: T) {
    def run: Unit = ??? // do stuff with x
  }
}


object Main extends A {
  val x: T = ???
  val runner = new Runner(x)

  def main(args: Array[String]): Unit = {
    runner.run
  }
}

关于为什么选择一个而不是其他的任何想法来帮助我朝着编写更好的代码迈出一步？它是否归结为最易读的内容以及平衡传递更少参数与使事情更清洁、更易读的权衡，还是有一种更聪明的方式来思考程序设计。

对学习如何更好地做出这类决定的地方有什么建议吗？

Answer 1

我使用 object当你想要一个简单的界面来做不改变任何状态的事情时(纯函数)。在 Math 中思考类作为一个例子。另外，如果你想实现 singleton您可以使用的设计模式object也。

我使用 trait如果您知道一堆不同类的对象将具有相同的接口(interface)。如果你不这样做，定义 trait 可能有点过头了。 .

如果你想要一个类的真实对象实例是因为你需要封装私有(private)属性的转换。当我知道我需要 abstract data-type 时，我通常会这样做。 ，即将隐藏实现细节的数据结构或实体。

请注意，正如 Jörg W Mittag 所说，这不像 Java，因为在 scala 中您可以使用类来定义对象。