Question

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

这一切都始于为实例提供ID，然后......为什么不在配对对象中提供集合？如果集合在那里，为什么不在那里使用所有方法来处理集合？因此，不再需要经理了。然而，一个特征是伴随对象通常只有一个名称，如Car（不像Cars或CarManager，它假设是多个），所以使用复数运算的方法在它们的耦合中看起来很奇怪使用对象名称的措辞。

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

Answer 1

这有效地将伴侣对象变成了单身，这更像是一种反模式，而不是一种好的设计模式。单元测试是造成这个问题的主要原因（许多人比以前更聪明了）。

对象理想情况下不应因为这些原因而维持任何形式的可变状态（这会导致维护噩梦信任我）。

Answer 2

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

我会看看蛋糕模式（见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
}

Scala - 在伴侣对象中实现“manager”模式？

2 个答案: