0

私は状態パターンで利益を得ることができるクラスを持っています。ただし、一般的な「型コードを状態/戦略に置き換える」リファクタリングは私の場合にはうまく適合しないようです。状態は他のオブジェクトを監視して計算され、型コード変数はありません。

私のクラスコードのほとんどは、呼び出されたときにいくつかの状態を「計算」し、その状態の関数を実行するだけです。

型コード変数を強制することは、次の理由で間違っていると感じます。

  1. ポリモーフィック関数が使用されているすべての場所で、「updateState()」関数を呼び出す必要があります。

  2. 私のクラスはもはや 100% の振る舞いではなくなります。

関数が呼び出されるたびに状態を計算する必要があるため、間違ったパターンを考えているのではないかと思います。

通常、私はこれをリファクタリングします:

if (this.someOtherThingIsRunning()) {
    ...
} else {
    ...
}

このような：

typecode.doSomething()
// that being polymorphic

それは奇妙に思えます：

updateTypeCode()
typecode.doSomething()

状態パターンはこの場合に適用されますか? 型コードなしでポリモーフィズムから引き出される代替戦略はありますか?

4

2 に答える 2

0

質問を書いているときに、型コードを関数にして、一時的な（関数スコープ）型コードを返すことができるかもしれないことに気づきました。好き：

typecode().doSomething()

このソリューションでは、状態が保存されることはありません。これは避けたいことです。しかし、間違ったパターンを使用しているために問題が発生したのではないかとまだ思っています。

于 2013-01-03T07:17:52.593 に答える
0

状態を保存することにオープンな場合は、State と Observer を組み合わせて、依存するクラスが変更されたときに状態を変更することを検討してください (すべての呼び出しをチェックするのではなく)。ただし、これが機能する特定のモデルのみがあります。

それ以外の場合object.doSomething()は、内側にチェックを入れてdoSomething()ください。この場合、デザイン パターンを使用しても大きな利点はありません (ただし、デザイン パターンの定義を少し緩めると、多くのことがそのように見なされます)。私はおそらく一緒に行きます：

doSomething()
{
  if (someOtherThingIsRunning())
    doOneThing();
  else
    doAnotherThing();
}

代替手段（すでに提案されている）は、上記のチェックインをtypecode()行い、メソッドを含む別のクラスを返すことdoSomething()です。

于 2013-01-03T08:02:05.833 に答える