Inheriting from a class that inherits from monobehaviour

Questions & Answers
1

Hey guys i was wondering if it is bad practice to inherit from a class you have made which also inherits from monobehaviour.

EX:

Item : Monobehaviour

Weapon : Item

Is this a bad practice? I need my weapon script to be a monobehaviour so i can place it on a GameObject and I have alot of functionality needed from Item already made. If i was to do it this way what would be the benefits/downfalls, and also would it cause the weapon script to be running 2 main functions each time? Such as calling Update from Item and Weapon each frame?

Thanks for the help guys any advice on this matter will be greatly appreciated as I am still trying to get into the programming side.

3

A bad idea? - No!, that’s the point in OOP :smiley:

Just some basics:

public class Item : Monobehavior
{
    public void SomeFunction() { Debug.Log("Item.SomeFunction"); }
}

public class Weapon : Item
{
    public void SomeFunction()
    {
        base.SomeFunction(); // Calls Item.SomeFunction
        Debug.Log("Weapon.SomeFunction");
    }
}

This first case is “hiding” a function because you implement the same function that is inherited from Item. I’ve seen a lot people that do such things. But that’s not good because a reference to a weapon class that is of type Item will not call the new function.

Weapon weaponRef = GetComponent<Weapon>();
weaponRef.SomeFunction(); // prints: Item.SomeFunction + Weapon.SomeFunction

Item itemRef = weaponRef;
itemRef.SomeFunction();   // prints just: Item.SomeFunction

Now the real OOP way:

public class Item : Monobehavior
{
    public virtual void SomeFunction() { Debug.Log("Item.SomeFunction"); }
}

public class Weapon : Item
{
    public override void SomeFunction()
    {
        base.SomeFunction(); // Calls Item.SomeFunction
        Debug.Log("Weapon.SomeFunction");
    }
}

Now the function is declared as “virtual”. In our Weapon-class we override the virtual function. That way the base function get “replaced” by the new version in the Weapon class.

Weapon weaponRef = GetComponent<Weapon>();
weaponRef.SomeFunction(); // prints: Item.SomeFunction + Weapon.SomeFunction

Item itemRef = weaponRef;
itemRef.SomeFunction();   // prints: Item.SomeFunction + Weapon.SomeFunction

You don’t have to call the inherited function in your derived class if you don’t need it.

public class Ammo : Item
{
    public override void SomeFunction()
    {
        Debug.Log("Ammo.SomeFunction");
    }
}

Ammo ammoRef = GetComponent<Ammo>();
ammoRef.SomeFunction(); // prints: Ammo.SomeFunction

Item itemRef = ammoRef;
itemRef.SomeFunction();   // prints: Ammo.SomeFunction

There are still some special cases but that’s the most important thing about OOP :wink:

5

Not an answer, Just a request.

Could a mod please clean up this answer. There is a big ass flame in the comments for @DanielSig 's answer that has absolutely nothing to do with this Q, And could lead to misinformed users and double Q’s.

The question was:

Inheriting from a class that inherits
from monobehaviour

Hey guys i was wondering if it is bad
practice to inherit from a class you
have made which also inherits from
monobehaviour.

Not all this other BS that is unrelated. “Oh look at me E-Penis”, helps no one.

Besides that, @DanielSig 's answer is out of context, and based on his own opinion that bares no relevance, to this Question, what so ever.

Thank You.

I necro’ed this? Of course I did. It’s still relevant…

2

I think it’s a good idea actually, but make sure you’re following the correct procedures to call the ‘base’ class as needed (a little different JS vs C#) Functions like Update and Start and such will only run the lowest-level subclass, so if you need to call something in Item from Weapon, you may need to be explicit about that, but it won’t run both, no.

4

I’m sorry but OOP is an outdated design pattern.
I used OOP for many years before I realized the beauty and power of the component-based design pattern and I don’t want to see others waste the same amount of time.
There’s a VERY GOOD reason why Unity favors the component-based pattern and encourages everyone to inherit only from Monobehaviors.

Making tightly coupled code is like gluing a driver to his seat and his clothes to his skin. Inheritance is the incarnation of tight coupling. How can one class be more tightly coupled to another than inheriting from it?

Code is supposed to be reused by creating reusable components and
we’re supposed to use SendMessage for all component-component communications.

Personally I use sendMessage only for discrete data (like OnDie, OnJump, OnSpawn etc). For continuous data (like IsAlive, IsGrounded, Speed, Health, Ammo etc.) I made an extension method for components so they can request data anonymously, in which any component with a fitting handler will reply.

The component-based pattern in Unity is very similar to the mediator pattern where each GameObject is in fact a mediator.

Once you see it…
…you’ll shit bricks!