2

私が Java でプログラミングしていたときは、オブジェクトとそれらのマネージャーを使用していました。ご存じのように、特定のクラスのオブジェクトのコレクションを保持し、それらを便利に管理できるクラス (通常はシングルトン) です。現在、Scala では、すべての機能をコンパニオン オブジェクトに配置し、別個のマネージャー オブジェクトを作成することを避けたいという状況にますます陥っています。

すべては、インスタンスに ID を与えることから始まります。そして、コンパニオン オブジェクトにコレクションを持たないのはなぜでしょうか? コレクションがそこにあるのなら、そこにコレクションを操作するためのすべてのメソッドがないのはなぜでしょうか? そのため、マネージャーはもう必要ありません。ただし、コンパニオン オブジェクトは通常、単一の名前 like Car(like ではない、CarsまたはCarManager複数を想定する) を持っているため、複数形で動作するメソッドは、オブジェクト名と組み合わせた言葉遣いが奇妙に見えるという特異な点があります。

この状況に関するあなたの意見を知りたいのですが、このアプローチが、一見不必要に肥大化したマネージャー パターンよりも好ましいかどうかを知りたいです。それに関する記事への参照も大歓迎です。

4

2 に答える 2

4

できるだけシンプルにするのが良いです。オブジェクト内のコレクションは確かに単純です。ただし、オブジェクトを静的オブジェクトに依存させないようにする必要もあります。これにより、堅固な構造が作成され、テストがより困難になります。

ケーキパターンを見てみましょう（ハードコーディングせずにケーキパターンで依存性注入を行う方法を参照してください）。このようにして、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 に答える