2

当我使用 Java 进行编程时，我曾经为它们提供对象和管理器。你知道，一个类（通常是单例），它将保存某个类的对象的集合，并可以方便地管理它们。现在，在 Scala 中，我发现自己越来越处于这种情况下，将所有功能放在伴随对象中并避免创建不同的管理器对象是很诱人的。

这一切都始于为实例提供 ID，然后......为什么不在伴随对象中包含集合？如果集合在那里，为什么不把所有的方法都放在里面呢？因此，不再需要经理。然而，一个特点是伴随对象通常只有一个名称 like Car（不喜欢Cars或CarManager假定多个），因此使用复数操作的方法在与对象名称的耦合措辞中看起来很奇怪。

我想知道您对这种情况的看法，并想知道这种方法是否比看似不必要的臃肿经理模式更可取。对任何文章的任何引用也将不胜感激。

4

2 回答 2

4

越简单越好；对象内部的集合确实很简单。但是，您还应该避免使您的对象依赖于静态对象。这将创建一个刚性结构，并使测试更加困难。

我会看一下 cake-pattern（请参阅How do you do dependency injection with the Cake pattern without hardcoding?）。这样，您可以将 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
}
于 2012-05-03T10:24:14.590 回答
3

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

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

于 2012-05-03T09:26:43.300 回答