State machine with interface-separated states

Question

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

Seems to be some good answers in, [Is there a typical state machine implementation pattern?](https://stackoverflow.com/q/133214/1371329) Also note: there is a [difference between a state machine and the state pattern](https://stackoverflow.com/q/19859531/1371329). In the pattern, states must be polymorphic: each state presents the same API. In the machine, transitioning to a new state can result in a new set of operations. Thus the pattern focuses on designing the behavior _within_ states, while the machine focuses on designing the transitions _between_ states. — jaco0646, Nov 15 '22 at 23:22
For this all states would implement the same interface, but that doesn't mean that a particular interface parameter or method is acted upon by that state. Also, don't be afraid to have states within states if that is what your system requires. — ChrisBD, Nov 17 '22 at 11:30
If you feel that my reply was helpful, you can upvote or mark my reply as an answer.[How does accepting an answer work?](https://meta.stackexchange.com/questions/5234/how-does-accepting-an-answer-work) — StepUp, Nov 22 '22 at 07:49

Hamidreza Aliyari · Answer 1 · 2022-11-14T20:16:09.037

0

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

edited Nov 14 '22 at 20:16

answered Nov 14 '22 at 20:15

Hamidreza Aliyari

26
2

Yup, that could be a way, but.. usually those methods are concrete - different params, also they called through API and do concrete logic. So - there are 2+ methods that context supposed to do, but each of them are allowed in different states. In some way state is a validation if the action allowed or not – pavdan Nov 14 '22 at 20:48
there is another way to implement. you can add 'NextState' and 'PreviousState'. then you can make decision to go where next... or you can back to another previous state when some logics weren't met. – Hamidreza Aliyari Nov 16 '22 at 07:57

StepUp · Answer 2 · 2022-11-17T11:10:40.260

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:)");
    }
}

State machine with interface-separated states

2 Answers2