7

私の理解では、フライウェイトパターンの目的は、共通の外部状態を共有することにより、メモリフットプリントを減らし、パフォーマンスを向上させることです。共有状態を静的フィールドに格納するよりもパターンを実装することを好むのはなぜですか？

次の例を考えてみましょう：http ：//www.oodesign.com/flyweight-pattern-wargame-example-java-sourcecode.html

ここに画像の説明を入力してください

私が正しければ、この例のポイントは、単一のSoldierImpオブジェクトへの参照を保持することにより、SoldierClientクラスのすべてのインスタンス間で共通の状態（soldierGraphicalRepresentationオブジェクト）を共有することです。

この設計の実装に手間がかかるのはなぜですか？SoldierClientクラスを次のように宣言したくなるでしょう。

public class SoldierClient implements Soldier 
{
    protected static Object soldierGraphicalRepresentation;
    private int currentLocationX;
    private int currentLocationY;

    static SoldierImp()
    {
        soldierGraphicalRepresentation = LoadGraphicalRepresentation();
    }

    public void moveSoldier(int previousLocationX, int previousLocationY, int newLocationX, int newLocationY) {
        // do stuff with the graphical representation

    }
}

このようにして、SoilderClientのすべてのインスタンスが、同じsoldierGraphicalRepresentationオブジェクトへの参照を共有し、同じ目標が達成されます。私が間違っている？

4

2 に答える 2

11

パターンのポイントは、200 人の「大きな赤」の兵士が同じ「大きな赤」のグラフィック表現を共有したり、300 人の「小さな青」の兵士が同じ「小さな青」のグラフィック表現を共有したりできることです。 static の場合、すべての兵士は同一になります。

于 2013-02-23T14:42:33.997 に答える
3

静的フィールドは、赤/緑/青のグラフィック表現がいくつあっても機能します。static フィールドの唯一の問題は、Single Responsibility Principleに違反していることです。ご覧のとおり、SoldierClientクラスには 2 つのジョブがあります。

  1. グラフィック表現のプールの管理
  2. 典型的な仕事SoldierClient

この設計では、これら 2 つのジョブのいずれかを別のコンテキストで再利用することは非常に困難です。たとえば、Monsterグラフィック表現を共有する必要があるオブジェクトに対してプールを再利用することはできません。典型的なSoldierClientものは、プールとは関係のない別のコンテキストでは使用できません。

于 2016-10-12T10:00:23.957 に答える