カプセル化を中断するラムダを返すための悪い設計記号です

Question

Gameクラスがあり、それはGeneratorのクラスによって生成されるいくつかのリソースを必要とします。すべてのゲームには独自のジェネレータがあり、ジェネレータはインスタンス化するための重いオブジェクトであるため、Gameはインスタンスでオブジェクトプールを保持します。

private MapBoardGenerator(Game game) { 
    super(game); 
} 

public static MapBoardGenerator getInstance(Game game) { 
    MapBoardGenerator instance = game.getGenerator(MapBoardGenerator.class); 
    if (instance == null) { 
     instance = new MapBoardGenerator(game); 
     game.addGenerator(MapBoardGenerator.class, instance); 
    } 
    return instance; 
} 

この静的メソッドはGeneratorを拡張するすべてのクラスでほとんど同じである：すべての発電機では、私はこれらのようなメソッドを持っています。

私はSupplier<MapBoardGenerator>ので、コントロールが別の場所で行われますgameに提供されてやりたいとgetInstance方法は、単純に次のようになります。私はプライベートコンストラクタを呼び出すサプライヤーを渡すと

public static MapBoardGenerator getInstance(Game game) { 
    return game.getInstance(MapBoardGenerator.class, MapBoardGenerator::new); 
} 

が何か問題はありますか？それは大学のプロジェクトであり、デザインはここでは大変重要です。

Answer 1

プライベートコンストラクタをSupplierのインスタンスとして渡しても、コンストラクタがSupplierのインスタンスとして渡されるという理由からカプセル化が中断されません。インスタンスの受信者（この場合はGame）は、Supplierがどのように実装されているのか全く分かりません。それはSupplierインターフェイスを満たしているということだけです。それは何ですかインターフェイスへのプログラミングはすべてです。呼び出し側が具体的な実装を提供しても、受信側は実装が実現するインターフェイスのみを認識します。 Gameが取得している具体的な実装が分かっていれば、カプセル化に違反します。 SupplierGameに渡すと、またはアプリケーションのより大きな文脈で意味を持たないかもしれないかもしれないが、少なくともそれはMapBoardGeneratorのカプセル化に違反しない

注意。

Answer 2

私の2セント：多分タマネギのアーキテクチャを見てください。オニオンのアーキテクチャでは、ビジネス（ゲーム？）はインフラストラクチャコンポーネント（ジェネレータ？）によって参照されます。これは、ジェネレータインスタンスからのラムダ式の注入（またはデリゲート）をゲームインスタンスに含めることで、レイヤと責任を適切に分離した状態に保つことができます。

あなたはリフレクション経由で新しいインスタンスをインスタンス化する必要があり、なぜ私は...（私にとってそれはハックですが、私はC＃のから来て、多分この発言はありませんが適切である）循環参照について