define several same interfaces vs one interface for different objects?

Suppose we want to implement IState interface for a player like below and use state design pattern

Code (CSharp):

1. public interface IState{
2.    void Start();
3.    void Exit();
4.    void Update();
5. }

Also we want to implement IState for the other object like an item or an interactive object. We must define other IState interface called for example IItemState even it is the same as IState?
because I think if we want to change it later, we need to define a new interface

 

I recommend both of them because both of them are useful in their own use cases.

But the "define several same interfaces" approach is better because you can gain the same goal using this, but you can't achieve them using the second one "one interface for different objects".

Hope this helps.
Thanks.

 

Frankly you should just use the single IState interface for now. If you want to change it in the future, only then you will refactor the code and create the second interface. This way you keep it simple, and there's no clutter in the code base caused by solutions, which in reality might never be used.

 

main purposes for using a interface is so you can treat multiple implementations as if they are the same. Are there any situations where you would need to treat your player states and your item states the same? The answer to that is the answer to your question.

Outside of state machines i tend to treat if something has a interface, as if this object can do a certain action. As a result you will see a lot of IAdjective named interfaces (IConsumable, IDamagable, etc) and these will be reused on a large amount of objects, where i might want to check if said object can receive damage, or be used etc.

 

thank you all
"any situations where you would need to treat your player states and your item states the same"
yes it is important. if I want the same behaviour (I don't want because player states and item states have different types) I must create one interface and vice versa

Refactoring wastes much time, I think.
Suppose I am going to define several methods inside one interface: OnTriggerEnter,OnTriggerExit,OnCollisionEnter, etc(only one for example IItemState)

 

As long as you are sure, or almost certain that those multiple interfaces are going to be used in different contexts, or you need to have a quick way of telling what kind of a object is handled just by the interface name, then you should go for more than one.

With that in mind, the answer to your question from the first post : "We must define other IState interface called for example IItemState even it is the same as IState?" is a yes, if you want a specialized handling of IItemState and IState interfaces. Otherwise is a no.

Regarding refactor time, If the time comes for a refactor of the item classes, and they are currently using the IState interface, all you have to do is to create a specialized interface IItemState, and add it to the item classes. This way they now implement IState and IItemState interfaces. You can create new specialized code for handling IItemState, without loosing the ability to also use the solutions for generic IState handling.