Should I make an interface to avoid direct reference of concrete classes in this case?

Hi all :slight_smile:

I’m working on turn-based strategy game managing a country. So I have game objects representing each region(logically). And in that game object, the most important component is RegionObj:Monobehaviour.
Here is the simplified version of it.

public class RegionObj:MonoBehavior {
    public List<RegionComponentBase> regionComps;

    public void Init()
    {
        regionComps.ForEach(comp => comp.Init());
    }

    public void Loop()
    {
        regionComps.ForEach(comp=>comp.Loop())
    }
}

public abstract class RegionComponentBase : MonoBehaviour
    {
        public abstract void Init();
        public abstract void Loop();
    }

RegionComponentBase holds data and logics for RegionObj. So there are many classes inheriting this.

Problem:

I want make Actions that manupulates RegionObj, would it be Ok to just take RegionObj as parameter or field and take references of RegionComponentBases to manipulate?. Or should I make an another interface(or maybe class) like IRegionManipulator which have methods for Action to use?

Thanks for reading my question!

So I have game objects representing each region(logically).

So there are many classes inheriting this.


That doesn’t sound like interfaces are going to help. What it sounds like is a misuse of both inheritance and classes.

How different are the regions in terms of their schema? If not at all then you should be using instances of the same type not inheritance. If they are slightly different behaviourally then there are better patterns than inheritance for that too. For example a simple strategy pattern would probably even serve you better.


Unity is heavily built around the idea of polymorphism. Where game objects are differentiated by their component configuration.

It’s done that way for a reason and I would try to default to thinking (at least if you are a beginner) that if you are using inheritance most of the time there is a better way to solve the problem.