koobas.hobune.stream
Should I make an interface to avoid direct reference of concrete classes in this case?
Hi all :)
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!
Do you $$anonymous$$d sharing some information about the variations of the derived classes? To show why you have a lot of inherited classes?
If you upload some examples of your inheritance I can possibly offer some alternative ways to do it which will help.
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.
Sorry I didn't write clearly.
Well the word "this" dose not mean RegionObj. It means RegionComponentBase. Each RegionComponentBase holds different data and acts with different logic during loopSo there are many classes inheriting this.
No that still applies I just misspoke about what your base class was.
Classes are not constructs that you use to specify different value/ data configurations. They are to specify the shape of the data you need to store i.e. a blueprint. Instances of a class are how you specify the data/ state configuration of that schema/ shape.
Inheritance is a blunt tool for this job and could get you into a lot of problems. It sounds like you are already experiencing one effect of in-proper/anti-pattern use of inheritance which is commonly referred to as a class explosion.
If you have different behaviour then as I said there are much better patterns for at runtime and statically deciding what behaviours those are.
Hmm.... I don't think I completely understood your words, but I'll think upon it. Thank you for the answer anyway!
