Scala - 在伴随对象中实现"manager"模式？

Question

当我用Java编程时，我曾经有对象和管理器。你知道，一个类(通常是单例(，它将保存某个类的对象集合，并让它们方便地管理它们。现在，在 Scala 中，我发现自己越来越多地处于这样一种情况：将所有功能放在一个配套对象中并避免创建不同的管理器对象是非常诱人的。

这一切都始于为实例提供 ID，然后...为什么不在伴随对象中拥有集合？如果集合在那里，为什么不让所有方法都在那里处理集合呢？因此，不再需要经理。然而，一个特点是，伴随对象通常有一个像Car这样的名称(不像假定复数的Cars或CarManager(，因此使用复数运算的方法在与对象名称的耦合措辞中看起来很奇怪。

我想知道你对这种情况的看法，并想知道这种方法是否比看似不必要的臃肿经理模式更可取。如能提及这方面的任何条款，也将不胜感激。

Answer 1

尽可能简单是好的;对象内部的集合确实很简单。但是，您也应避免使对象依赖于静态对象。这将创建一个僵化的结构，并使测试更加困难。

我会看一下蛋糕模式(请参阅如何在没有硬编码的情况下使用 Cake 模式进行依赖注入？通过这种方式，您可以将 CarManager 放在一个对象中，并通过 CarRepositoryComponent 将其混合到您的依赖项中。

非编译示例：

val someService = new SomeService 
  with MyRepairServiceComponent with CarCollectionRepositoryComponent
someService.repairCar(8)
trait SomeService extends RepairServiceComponent with CarRepositoryComponent {
  def repairCar(id: Int): Status = repairService.repair(carRepository.get(id));
}
trait CarRepository {
  abstract def get(id: Int): Car
}
trait CarRepositoryComponent {
  abstract def carRepository: CarRepository
} 
object CarManager extends CarRepository {
  private var cars = Map[Int, Car]()
  def get(id: Int): Car = cars(id)
}
trait CarCollectionRepositoryComponent {
  def carRepository = CarManager
}

Answer 2

这有效地将伴随对象变成了单例，这更像是一种反模式，而不是一种良好设计的模式。单元测试是造成这个问题的主要原因(许多比我聪明的人之前已经多次讨论过这个问题(。

理想情况下，由于这些原因，对象不应该保持任何类型的可变状态(相信我，这会导致维护噩梦(。