7

単純な列挙を使用して、エンティティの状態を表すことがよくあります。問題は、状態に大きく依存する動作を導入した場合、または状態遷移が特定のビジネス ルールに従う必要がある場合に発生します。

次の例を見てください (列挙を使用して状態を表します)。

public class Vacancy {

    private VacancyState currentState;

    public void Approve() {
        if (CanBeApproved()) {
            currentState.Approve();
        }
    }

    public bool CanBeApproved() {
        return currentState == VacancyState.Unapproved
            || currentState == VacancyState.Removed
    }

    private enum VacancyState {
        Unapproved,
        Approved,
        Rejected,
        Completed,
        Removed
    }
}

Reject、Complete、Remove などのメソッドを追加すると、このクラスはすぐに非常に冗長になることがわかります。

代わりに、各状態をオブジェクトとしてカプセル化できる State パターンを導入できます。

public abstract class VacancyState {

    protected Vacancy vacancy;

    public VacancyState(Vacancy vacancy) {
        this.vacancy = vacancy;
    }

    public abstract void Approve(); 
    // public abstract void Unapprove();
    // public abstract void Reject();
    // etc.

    public virtual bool CanApprove() {
        return false;
    }
}

public abstract class UnapprovedState : VacancyState {

    public UnapprovedState(vacancy) : base(vacancy) { }

    public override void Approve() {
        vacancy.State = new ApprovedState(vacancy);
    }

    public override bool CanApprove() {
        return true;
    }
}

これにより、状態間の遷移、現在の状態に基づいたロジックの実行、または必要に応じて新しい状態の追加が簡単になります。

// transition state
vacancy.State.Approve();

// conditional
model.ShowRejectButton = vacancy.State.CanReject();

このカプセル化はきれいに見えますが、十分な状態が与えられると、これらも非常に冗長になる可能性があります。代わりにポリモーフィズムを使用することを提案しているState Pattern Misuse に関する Greg Young の投稿を読みました (そのため、ApprovedVacancy、UnapprovedVacancy などのクラスが必要です) が、これがどのように役立つかわかりません。

このような状態遷移をドメイン サービスに委任する必要がありますか?それとも、この状況での状態パターンの使用は正しいですか?

4

1 に答える 1

6

To answer your question, you shouldn't delegate this to a domain service and your use of the State pattern is almost correct.

To elaborate, the responsibility for maintaining the state of an object belongs with that object, so relegating this to a domain service leads to anemic models. That isn't to say that the responsibility of state modification can't be delegated through the use of other patterns, but this should be transparent to the consumer of the object.

This leads me to your use of the State pattern. For the most part, you are using the pattern correctly. The one portion where you stray a bit is in your Law of Demeter violations. The consumer of your object shouldn't reach into your object and call methods on it's state (e.g. vacancy.State.CanReject()), but rather your object should be delegating this call to the State object (e.g. vacancy.CanReject() -> bool CanReject() { return _state.CanReject(); }). The consumer of your object shouldn't have to know that you are even using the State pattern.

To comment on the article you've referenced, the State pattern relies upon polymorphism as it's facilitating mechanism. The object encapsulating a State implementation is able to delegate a call to whichever implementation is currently assigned whether that be something that does nothing, throws an exception, or performs some action. Also, while it's certainly possible to cause a Liskov Substitution Principle violation by using the State pattern (or any other pattern), this isn't determined by the fact that the object may throw an exception or not, but by whether modifications to an object can be made in light of existing code (read this for further discussion).

于 2012-04-04T14:44:58.093 に答える