Should I avoid using object inheritance as possible to develop a game?

Question

I prefer OOP features when developing games with Unity. I usually create a base class (mostly abstracted) and use object inheritance to share the same functionality to the various other objects.

However, I recently heard from someone that using inheritance must be avoided, and we should use interfaces instead. So I asked why, and he said that "Object inheritance is important of course, but if there are lots of extended objects, relationship between classes are deep coupled.

I'm using an abstract base class, something like WeaponBase and creating specific weapon classes like Shotgun, AssaultRifle, Machinegun something like that. There are so many advantages, and one pattern I really enjoy is polymorphism. I can treat the object created by subclasses as though they were the base class, so that the logic can be drastically reduced and made more reusable. If I need to access the fields or methods of the sub-class, I cast back to the sub-class.

I don't want to define same fields, commonly used in different classes, like AudioSource/Rigidbody/Animator and lots of member fields I defined like fireRate, damage, range, spread and so on. Also in some cases, some of methods could be overwritten. So I'm using virtual methods in that case, so that basically I can invoke that method using the method from parent class, but if the logic should be different in child, I have manually overridden them.

So, should all these thing be abandoned as bad practices? Should I use interfaces instead?

Answer 1

Favour composition over inheritance in your entity and inventory/item systems. This advice tends to apply to game logic structures, when the way in which you can assemble complex things (at runtime) can lead to a lot of different combinations; that's when we prefer composition.

Favour inheritance over composition in your application-level logic, everything from UI constructs to services. For example,

Widget->Button->SpinnerButton or

ConnectionManager->TCPConnectionManager vs ->UDPConnectionManager.

...there is a clearly defined hierarchy of derivation here, rather than a multitude of potential derivations, so it is just easier to use inheritance.

Bottom line: use inheritance where you can, but use composition where you must. P.S. The other reason we may favour composition in entity systems is that there are usually many entities, and inheritance can incur a performance cost to access members on every object; see vtables.

Answer 2

You got a few nice answers already, but the huge elephant in the room in your question is this one:

heard from someone that using inheritance must be avoided, and we should use interfaces instead

As a rule of thumb, when somebody gives you a rule of thumb, then ignore it. This not only goes for "somebody telling you something", but also for reading stuff on the internet. Unless you know why (and can really stand behind it), such advice is worthless and often very harmful.

In my experience, the most important, and helpful concepts in OOP are "low coupling" and "high cohesion" (classes/objects know as little as possible about each other, and each unit is responsible for as few things as possible).

Low Coupling

This means that any "bundle of stuff" in your code should depend on its surroundings as little as possible. This goes for classes (class design) but also objects (actual implementation), "files" in general (i.e., number of #includes per single .cpp file, number of import per single .java file and so on).

A sign that two entities are coupled is that one of them will break (or need to be changed) when the other is changed in any way.

Inheritance increases coupling, obviously; changing the base class changes all subclasses.

Interfaces reduce coupling: by defining a clear, method-based contract, you can change anything about both sides of the interface freely, as long as you don't change the contract. (Note that "interface" is a general concept, the Java interface or C++ abstract classes are just implementation details).

High Cohesion

This means to have each class, object, file etc. be concerned with or responsible for as little as possible. I.e., avoid large classes that do a lot of stuff. In your example, if your weapons have completely separate aspects (ammo, firing behaviour, graphical representation, inventory representation etc.), then you can have different classes that represent exactly one of those things. The main weapon class then transforms into a "holder" of those details; a weapon object then is little more than a few pointers to those details.

In this example, you would make sure that your class representing the "Firing Behaviour" knows as little as humanly possible about the main weapon class. Optimally, nothing at all. This would, for example, mean, that you could give "Firing Behaviour" to any object in your world (turrets, volcanoes, NPCs ...) by just a snap of a finger. If you at some point in time want to change how weapons are represented in the inventory, then you can simply do so - only your inventory class knows about that at all.

A sign that an entity is not cohesive is if it grows larger and larger, branching out in several directions at the same time.

Inheritance as you describe it decreases cohesion - your weapon classes are, at the end of the day, big chunks who handle all kinds of different, non-related aspects of your weapons.

Interfaces indirectly increase cohesion by clearly splitting off responsibilities between the two sides of the interface.

What to do now

There still are no hard and fast rules, all of this is just guidelines. In general, as user TKK mentioned in his answer, inheritance is taught a lot in school and books; it is the fancy stuff about OOP. Interfaces are both probably more boring to teach, and also (if you go past trivial examples) a bit harder, opening up the field of dependency injection, which is not so clear-cut as inheritance.

At the end of the day, your inheritance-based scheme is still better than having no clear OOP design at all. So feel free to stick with it. If you wish to, you can ruminate/google a bit about Low Coupling, High Cohesion and see if you wish to add that kind of thinking to your arsenal. You can always refactor to try that out if you wish to, later; or try out interface-based approaches on your next larger new module of code.

Answer 3

The idea that inheritance must be avoided is simply wrong.

There exists a coding principle called Composition over Inheritance. It says that you can achieve the same things with composition, and it's preferable, because you can reuse some of the code. See Why should I prefer composition over inheritance?

I have to say I like your weapon classes and would it do the same way. But i haven't made a game by now...

As pointed out by James Trotter, composition could have some advantages, especially in the flexibility at runtime to change how the weapon works. This would be possible with inheritance, but it's more difficult.

Answer 4

The problem is that inheritance leads to coupling--your objects need to know more about each other. That's why the rule is "Always favor composition over inheritance". This doesn't mean NEVER use inheritance, it means use it where it's completely appropriate, but if you are ever sitting there thinking "I could do this both ways and they both kind of make sense", just go straight to composition.

Inheritance can also be kind of limiting. You have a "WeaponBase" that can be an AssultRifle--awesome. What happens when you have a double-barrel shotgun and want to allow the barrels to fire independently--a little harder but doable, you just have a single-barrel and double-barrel class, but you can't just mount 2 single barrels on the same gun, can you? Could you mod one to have 3 barrels or do you need a new class for that?

What about an AssultRifle with a GrenadeLauncher underneath--hmm, a little tougher. Can you replace the GrenadeLauncher with a flashlight for nighttime hunting?

Finally, how do you allow your user to make the preceding guns by editing a config file? This is difficult because you've hard-coded relationships that might be better off composed and configured with data.

Multiple inheritance can fix some of these trivial examples somewhat, but it adds it's own set of problems.

Before there were common sayings like "Prefer composition over inheritance", I found this out by writing an overly complex inheritance tree (which was awesome fun and worked perfectly) then finding out that it was really difficult to modify and maintain later. The saying is just so you have an alternative and compact way to learn and remember such a concept without having to go through the whole experience--but if you wish to use inheritance heavily I recommend just keeping an open mind and evaluating how well it works for you--nothing terrible is going to happen if you use inheritance heavily and it might be a great learning experience at worst (at best it might work fine for you)

Answer 5

Contrary to the other answers, this has nothing to do with inheritance vs. composition. Inheritance vs. composition is a decision you make regarding how a class will be implemented. Interfaces vs. classes is a decision that comes before that.

Interfaces are the first-class citizens of any OOP language. Classes are secondary implementation details. New programmers' minds are severely warped by teachers and books that introduce classes and inheritance before interfaces.

The key principle is that whenever possible, the types of all method parameters and return values should be interfaces, not classes. This makes your APIs much more flexible and powerful. The vast majority of the time, your methods and their callers should have no reason to know or care about the actual classes of the objects they're dealing with. If your API is agnostic about implementation details, you can freely switch between composition and inheritance without breaking anything.

Answer 6

Whenever someone tells you that one specific approach is the best for all cases, it's the same as telling you that one and the same medicine cures all diseases.

Inheritance vs composition is an is-a vs has-a question. Interfaces are yet another (3rd) way, appropriate for some situations.

Inheritance, or the is-a logic: you use it when the new class is going to behave and be used completely like (outwardly) the old class that you're deriving it from, if the new class is going to expose to the public all the functionality that the old class had... then you inherit.

Composition, or the has-a logic: If the new class just needs to internally use the old class, without exposing the old class' features to the public, then you use composition - that is, have an instance of the old class as a member property or a variable of the new one. (This can be a private property, or protected, or whatever, depending on the use case). The key point here is that this is the use case where you don't want to expose the original class features and use to the public, just use it internally, while in the inheritance case you're exposing them to the public, through the new class. Sometimes you need one approach, and sometimes the other.

Interfaces: Interfaces are for yet another use case - when you want the new class to partially and not completely implement and expose to the public the functionality of the old one. This lets you have a new class, class from a totally different hierarchy from the old one, behave as the old one in some aspects only.

Let's say that you have assorted creatures represented by classes, and they have functionalities represented by functions. For example, a bird would have Talk(), Fly() and Poop(). Class Duck would inherit from class Bird, implementing all of the features.

Class Fox, obviously, cannot fly. So if you define the ancestor to have all the features, then you could not derive the descendant properly.

If, however, you break the features into groups, representing each group of calls with an interface, say, IFly, containing Takeoff(), FlapWings() and Land(), then you could for the class Fox implement functions from ITalk and IPoop but not IFly. You would then define variables and parameters to accept objects that implement a specific interface, and then the code working with them would know what it can call... and can always query for other interfaces, if it needs to see if other functionalities are also implemented for the current object.

Each of these approaches has use cases when it's the best one, no one approach is an absolute best solution for all cases.

Answer 7

For a game, especially with Unity, which works with an entity-component architecture, you should favor composition over inheritance for your game components. It's much more flexible, and avoids getting into a situation where you want a game entity to "be" two things that are on different leaves of an inheritance tree.

So, for example, say you have a TalkingAI on one branch of an inheritance tree, and VolumetricCloud on another separate branch, and you want a talking cloud. This is hard with a deep inheritance tree. With entity-component, you just create an entity that has a TalkingAI and Cloud components, and you're good to go.

But that doesn't mean that in, say, your volumetric cloud implementation, you shouldn't use inheritance. The code for that might be substantial and consist of several classes, and you can use OOP as needed for it. But it will all amount to a single game component.

As a side note, I take some issue with this:

I usually create a base class (mostly abstracted) and use object inheritance to share the same functionality to the various other objects.

Inheritance is not for code reuse. It's for establishing an is-a relationship. A lot of the time these go hand in hand, but you have to be careful. Just because two modules may need to use the same code, it doesn't mean that one is of the same type as the other.

You can use interfaces if you want to, say, have a List<IWeapon> with different types of weapons in it. This way, you can inherit from both the IWeapon interface, and the MonoBehaviour subclass for all weapons, and avoid any issues with the absence of multiple inheritance.

Answer 8

You seem to not understand what an interface is or does. It took me about 10+ years of thinking about OO and asking some really smart people questions was I able to have an ah-ha moment with interfaces. Hope this helps.

The best is to use a combination of them. In my OO mind modeling the world and people lets say, some deep example. The soul is interfaced with the body through the mind. The mind IS the interface between the soul (some consider intellect) and the commands it issues to the body. The minds interface to the body is the same for all people, functionally speaking.

The same analogy can be used between the person (body and soul) interfacing with the world. The body is the interface between the mind and the world. Everyone interfaces to the world in the same way, the only uniqueness is HOW we interact with the world, that is how we use our MIND to DECIDE HOW we interface/interact in the world.

An interface is then simply a mechanism to relate your OO structure with another different OO structure with each side having different attributes that must negotiate/map to each other to produce some functional output in a different medium/environment.

So for the mind to call the open-hand function it must implement the interface nervous_command_system with THAT having it's own API with instructions how to implement all the requirements necessary before calling open-hand.