Designing to Interfaces

Unity Engine
1

Hey, I’m new to unity, having just jumped on with the 2D update. Also, my commercial programming experience is admittedly much more Java oriented than C#. That said, I’m coming up against a bit of a design question right off the bat.

Using MonoBehaviour’s “GetComponent” to access another MonoBehaviour Component on the current/child gameObject seems like a useful design approach. It’s allowed me to offload a lot of factory / configuration work onto the inspector. However, given that Component is a class (vs an interface) and GetComponent requires referencing the component child class through its generic, this approach quickly introduces a lot of tight coupling between those classes.

    public interface PlayerCharacter {
        void DoPlayerStuff();        
    }

    public interface RobotCharacter {
        
    }

    public class PlayerCharacterImpl : MonoBehaviour, PlayerCharacter
    {
        public void DoStuff() { }
    }

    public class RobotCharacterImpl: MonoBehaviour, RobotCharacter
    {
        void Start()
        {
            PlayerCharacter player = GetComponent<PlayerCharacterImpl>(); //this class now tightly bound to PlayerCharacterImpl
            //PlayerCharacter player = GetComponent<PlayerCharacter>(); //Impossible, PlayerCharacter not of type Component
            player.DoPlayerStuff();
        }   


    }

I’d love an API similar to GetComponent, but which allowed an unbounded generic that was assignable from an interface and not only assignable from component. Looser coupling would be allowed and given that Component exposes the world, interfaces would introduce some encapsulation between the two scripts.

I’m cooking up my own quick solution but I figured someone must have come up against this before and has a design solution out there. Alternatively, am I just way over-engineering this or using the functionality inappropriately?

2

Here is a solution, but, as I think, this could be wrong way for game development

public class RobotCharacterImpl : MonoBehaviour, RobotCharacter
{
    void Start()
    {
        PlayerCharacter player = (PlayerCharacter)GetComponent(typeof(PlayerCharacter)); // this works
        //PlayerCharacter player = GetComponent<PlayerCharacterImpl>(); //this class now tightly bound to PlayerCharacterImpl
        //PlayerCharacter player = GetComponent<PlayerCharacter>(); //Impossible, PlayerCharacter not of type Component
        player.DoPlayerStuff();
    }
}

UPD:
This way could bring you to hierarchical object oriented structure of classes that works well in the typical business oriented software, enterprise software development and small games. But in most games this approach won’t work well because of not enought flexibility (yes, I know it sounds a little bit strange, maybe vertical-flexibility is more suitable term here, see fragile base class problem).

Unity Engine offers to use component-based architecture which allow to avoid this dependencies on based classes or interfaces, I recommend to read the acticle of Ray Wenderlich - Introduction to Component Based Architecture in Games (Introduction to Component Based Architecture in Games | Kodeco), there are described this problem and supposed 3 ways to implement such architecture (2nd is very similar as Unity supposed).

3

maybe you look for this : Unity Asset Store - The Best Assets for Game Making

4

Thanks for the link! Reading through it now.