Interface-based implementation for (NI) State Pattern Actor

[Oli_Wachno]

Hi,

is anybody aware of the existence of an interface bsed implementation of the State Pattern Actor?

(https://forums.ni.com/t5/Actor-Framework-Discussions/Implementing-the-State-Pattern-in-Actor-Framewo...)

Cheers

Oli

[AristosQueue (NI)]

Do interfaces change that particular pattern other than "the ancestor class now is an interface"? Some patterns change substantially with the introduction of interfaces, but I don't think this is one of them. If you know of some broader change, I'm interested in hearing about it.

[justACS]

I've been trying to decide if it's appropriate to make an interface version.  I'm currently leaning (strongly) toward not.

Interfaces are about how actors interact with other actors.  AristosQueue gave me a great one line definition of the role of an interface, which I've pulled into the update of the AF course:  "an interface defines how actor X talks to actor Y."

State pattern, on the other hand, is about changing how an actor (or any class) responds to a message, not about the messages to which the actor responds.  As I see it, the pattern is about the actor's core identity, which has nothing to do with how other actors talk to it.

Write a stateful actor that has the behavior you desire, then use an interface to adapt it to the environment where you need it.

[AristosQueue (NI)]

My previous answer was "could you do it?"  Yes.

Allen answered "should you do it?" No.

In the context of the Actor Framework, I tend to agree with Allen. When doing a state change, I usually (always?) have to shuttle data from the old actor object to the new actor object. Sure, that can all be done by interface methods, but having an ancestor class that can just unbundle and rebundle fields from one object to the other seems a lot simpler. Remembering the trio of "Identity-State-Behavior", the state pattern allows a new object to take over the state of the state machine... an interface doesn't define state, so it has to define a behavior for moving state. Awkward.

[Oli_Wachno]

Thanks for your comments!

I'm am starting to refactor a rather large AF based application with "broad" inheritance hierarchy (which is also under discussion).

I remember, that I was not very happy back then to "merge" the State Actor functionality in manually somewhere in the middle of the inheritance tree.

So basically I was wondering if the usage of an interface based State Actor might make things simpler there.

Though I am perfectly aware that this "merge" might just have been a workaround for a flawed object hierarchy 😉

[AristosQueue (NI)]

I'm finding it hard to imagine a state pattern scenario where the state classes could be reused in other contexts. Unless you can come up with such a beast, you should be able to just create a parent class for the states and then inherit from that. I don't know what kind of merging is involved since the state classes are pretty much designed to fit the specific context from their inception. Changing an existing class to become a state of a system is not something I can imagine having to do -- I'm not saying you didn't, just that it is sufficiently exotic that even though you hit it once, I would wager that you will not hit it again in the future.