0
\$\begingroup\$

In our project we used to have a PlayerObject class and then Unit and Building derived from that class. We recently started taking a look at Bolt, which requires classes that define objects that may have different states to inherit directly from a Bolt class. So Unit and Building can no longer inherit from PlayerObject.

This turns out to create a few problems, a significant portion of our game uses PlayerObject rather than Unit or Building to perform actions that are the same for both. Separating them would really throw a wrench into the program, since you now have to have methods that use both Unit and Building instead of just PlayerObject.

I thought making a common interface IPlayerObject, and defining common properties and methods in the interface and making Building and Unit both derive from IPlayerObject would do the trick. I did not think it through enough and came to find out that if I use IPlayerObject I can no longer access MonoBehaviour methods and fields (such as transform, or render).

Can I make this in such a way that I can use the IPlayerObject type, with a Unit or Building type and still have access to MonoBehaviour through that interface?

If not, is there a proper way to do this, past just adding in extra methods to handle Unit and Building types separately.

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ I'm not sure how Bolt works, but you might be able to get away with composition instead of inheritance. See this question's answers for other options. \$\endgroup\$
    – House ♦
    Mar 2, 2015 at 1:06
  • \$\begingroup\$ It is not much a thing with Bolt, but rather having two different types that would do well to be treated like a single type by many parts of the application. The issue is if I use a common interface, accessing those types through that interface cuts me off from MonoBehavior. I'll look into composition, it seems like a complicated topic to cover. \$\endgroup\$
    – Douglas Gaskell
    Mar 2, 2015 at 2:05

1 Answer 1

Reset to default
1
\$\begingroup\$

I guess you have two suboptimal options here. So my short answer would be:No, you cannot do this.

Either go the way of composition (as suggested in the comments) or design your IPlayer Interface. That, however requires you to write a complete Interface for MonoBehaviour. If you have done that, I don't think you'll going to be happy because you would basically have to implement all the MonoBehavior implementation again on the Class which inherits IPlayerObject.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Thank you for the reply. I've been doing some reading on composition, even if I went that route, would I still not lose access to MonoBehavior when using any of the interfaces that a specific class is derived from? \$\endgroup\$
    – Douglas Gaskell
    Mar 2, 2015 at 16:28
  • \$\begingroup\$ The inherent problem with both approaches is, that you cannot inherit from two classes. Therefore you cannot do typechecks the "normal" way. At least not unless you have MonoBehavior and bolt both implement the same custom Interface you wrote. \$\endgroup\$
    – Structed
    Mar 3, 2015 at 12:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .