State machine with interface-separated states-CodePudding

In a classic version of states, each state implementing some interface. So we can pass execution to any current state

class Context
{
    private State _state;

    public void MethodA()
    {
        _state.MethodA();
    }

    public void MethodB()
    {
        _state.MethodB();
    }
}

But in my case. I have a gameplay feature. It offers something to buy. And it also has states, like "Active", "Buying", "Preparing", "Finished" and so on. From some of them buying is allowed, from others - not. In more abstract way - each of states implement only part of the context's interface methods. And methods may intersect

class ConcreteStateA
{
    public void MethodA()
    {
        // Do A
    }

    // No MethodB
}

class ConcreteStateB
{
    // No MethodA

    public void MethodB()
    {
        // Do B
    }
}

The question: is it any modification to use state machine this way? The current variation cause to directly check whether it's correct state or not before call in context. State classes hierarchy doesn't save from the problem of state type checking

CodePudding user response：

you can add an interface that has a method named 'Handle'. then you can implement that interface in your concrete class. by this approach you can just say what to do next from this state and you are not forced to implement other states.

see this: https://www.dotnettricks.com/learn/designpatterns/state-design-pattern-c-sharp

CodePudding user response：

I really like definition of State pattern used in wiki:

The state pattern is a behavioral software design pattern that allows an object to alter its behavior when its internal state changes. This pattern is close to the concept of finite-state machines. The state pattern can be interpreted as a strategy pattern, which is able to switch a strategy through invocations of methods defined in the pattern's interface.

Pay attention to this sentence:

allows an object to alter its behavior when its internal state changes. This pattern is close to the concept of finite-state machines

The above words mean that all methods are necessary and should be handled appropriately. I absolutely love this book "Head First Design Patterns". And this book shows how different states can be handled.

From your states, I made a conclusion that you are develping some vending machine. Let it be coffee vending machine. Let's say we have just one method PutMoney() in coffee vending machine.

So this is our abstraction of states:

public interface IState
{
    void PutMoney();
}

And it is a concrete implementation of ActiveState:

public class ActiveState : IState
{
    public void PutMoney()
    {
        Console.WriteLine("Please, 15 cents to get a cup of coffee!:)");
    }
}

it is a concrete implementation of BuyingState:

public class BuyingState : IState
{
    public void PutMoney()
    {
        Console.WriteLine("You have already put money. 
            Just choose desireed coffee!:)");
    }
}

it is a concrete implementation of PreparingState:

public class PreparingState : IState
{
    public void PutMoney()
    {
        Console.WriteLine("You have already chosen money. 
            We are preparing coffee for you!:)");
    }
}

it is a concrete implementation of FinishedState:

public class FinishedState : IState
{
    public void PutMoney()
    {
        Console.WriteLine("You have already bought coffeey. 
            No money is necessary! Just take coffee:)");
    }
}