9

これは、新しいアプリを設計しているときに何度も直面する問題です。これを説明するために、サンプル問題を使用します。

私は単純なゲームを書いているので、プレイヤーのリストを保持したいと考えています。私にはいくつかの選択肢があります...

  1. 一部のクラスで静的フィールドを使用する 
private  static ArrayList<Player> players = new ArrayList<Integer>();  
public Player getPlayer(int i){
    return players.get(i);
}

しかし、これはグローバルな状態です

  1. または、シングルトンを使用できます
class PlayerList{
    private PlayerList instance;
    private PlayerList(){...}
    public PlayerList getInstance() {
        if(instance==null){
            ...
        }
        return instance;
    } 
 }

しかし、これはシングルトンなので悪いです

  1. 依存性注入
class Game {
    private PlayerList playerList;
    public Game(PlayerList list) {
        this.list = list;
    }
    public PlayerList getPlayerList() {
        return playerList;
    }
}

これは良さそうですが、そうではありません。

Game 以外のオブジェクトを見る必要がPlayerListある場合 (これは通常のケースです) 、上記のいずれかの方法を使用して、Game クラスをグローバルに利用できるようにする必要があります。そのため、問題に別のレイヤーを追加するだけです。私は実際には何も解決しませんでした。

最適なソリューションは何ですか? （現在、私はシングルトンアプローチを使用しています）

4

3 に答える 3

4

そのため、DI コンテナーはライフサイクルを管理します。コンテナーのライフサイクルに関して、Playerlist をシングルトンにします。コンポーネントの完全なテスト可能性を提供し、コンテナー (あなたではない) を手を汚しましょう。

于 2009-09-01T20:19:42.760 に答える
2

依存性注入の背後にある考え方は、その名前が示すように、依存性を注入することです。そのため、プレイヤー リストについて知る必要のあるオブジェクトには、それが注入されます。通常、依存関係のルックアップやその他のメカニズムに切り替える前に、依存関係の注入をできるだけ広範囲に使用することは非常に理にかなっています。これにより、後でゲームを拡張して、レベルごとに異なるプレーヤー リストを作成したり、拡張を考えたりすることも可能になります。

于 2009-09-01T19:42:36.067 に答える
1

Game の外で PlayerList が必要な場合、おそらく Game はこれに対して間違ったクラスでしょうか? 他のオブジェクトが PlayerList を必要とする場合は、List も注入する必要があるか、リストを Game クラスではなくこのクラスに移動する必要があります。

Game、PlayerList、およびその他のクラスのライフタイムが異なる場合は、Factory を使用してそれらをグループ化することも検討してください。詳細については、このGoogle テスト ブログの記事を確認してください。

于 2009-09-01T19:50:15.863 に答える