0

おそらく、戦略パターンは私が求めているものではありません。私のコードが次のようになっているとします(疑似バージョン):

class Machine
{
    private Stack<State> _internals;

    public void DoOperation(Thingy x)
    {
        switch (x.operation)
        {
            case Op.Foo:
                DoFoo();
                break;

            case Op.Bar:
                DoBar();
                break;

            case Op.Baz:
                DoBaz();
        }
    }

    private void DoFoo()
    {
        // pushing and popping things from _internals, doing things to those States
    }

    private void DoBar()
    {
        // similarly large method to foo, but doing something much different to _internals
    }

    private void DoBaz()
    {
        // you get the idea...
    }
}

Foo、Bar、および Baz はかなり複雑なメソッド (極端に長くはないので、分割する必要があります) であるため、これらを共通のインターフェース (戦略パターン) を持つクラスに分割したいと考えています。_internals問題は、それらのクラスにカプセル化できないことです。つまり、それらのクラスのメソッドに渡すことができExecuteますが、それは悪い方法のようです。内部は単一の操作よりも長く持続するため、戦略クラスは内部自体を「所有」できません。渡された異なる Thingy を使用して、このマシンで複数の異なる操作を実行できます。

あなたが提案できる別のルートはありますか？

編集

これは一種のステート マシンですが、1 つの操作が特定の状態でのみ有効であるという意味ではありません。_internals現在の状態だけでなく、状態のスタックです。3 つの操作はいつでも実行できます。

4

1 に答える 1

0

あなたの戦略「戦略」は健全なようです。コードはこれまでのところ良さそうです。実際にインターフェースを宣言する必要がありますが、それは理解できたと思います。

_internals を渡せない理由がわかりません。それはインターフェース定義の一部です。そのメンバーは、「:_internals_data」などのタイプを受け入れることができます。

あなたはそれを少しまとめることができます、私のインターフェイスを次のように定義します

実行する

sendinlimitedsubsetofinternals

内部の変更されたサブセットを返します

次に、2 つのデータ メソッドは、単なる文字列の配列のようなものか、相互作用を本当に引き締めるためのものになります。次に、途中でシリアライゼーションを後で使用できます。

于 2013-08-24T23:58:12.880 に答える