Day 119 — Abstract Classes Vs Interfaces

Hey and welcome!

Today’s article is going to be a little bit different where I go over the key differences between Abstract Classes and Interfaces that I briefly covered as well as the best time to use them.

Let’s start by talking about functionality. When we created our Interface you may have noticed that the code was pretty bare an just looked like this:

float Health { get, set };
void Damage();

Unlike abstract classes we can’t actually define any functionality or logic for our methods in an interface so each time a script inherits the interface the logic has to be manually defined whereas for an abstract class you could have something like this:

float protected health = 3.0f
public virtual void Damage()
{
   Debug.Log("Ouch! I've been attacked!")
}

When a script inherits this abstract class they take on the logic as well defined in here automatically without the coder even needing to reference the Damage() method or health variable in the script. In short a Skeleton script that inherits this will automatically have a health variable with a property of 3 and a Damage() method all while the code looks like this:

public class Skeleton : Enemy
{
   // Even with no code here it already has the logic for the Damage      
   // method and their health is set to 3.0f!
}

Let’s take a different approach now and look at the best times to use an abstract class or an interface.

Abstract classes are best used when you have multiple objects in your game that share functionality that would end up as repeated code if we had them in their own unique classes. We’ve seen the example of having different enemy types that all have the same attributes and functionality like health and left-right movement but let’s think about a different example.

Let’s say we have a food/consumable system in the game that will heal the player a certain amount and also add on an extra effect to the player. There are multiple different types of food like bread, apples and chicken. These are all different in their own right but they also share similarities so it would make sense to create a Food class they can inherit on and override when necessary.

Interfaces on the other hand are best used when you have a particular attribute or logic that can be shared across different classes and objects that have no correlation between themselves.

As an example let’s say that our enemy can also consume food to heal themselves or maybe even an unrelated npc that can heal off of the food too! Between these three objects there’s very little in the way of similarities when it comes to the logic in their code so we can’t get away with getting them all to inherit from the same abstract class because they’ll have very little repeated code beyond the code to heal themselves off of food.

This scenario is where interfaces shine since even though there’s no repeated code we can get each class to inherit from an IHealing interface and force them to have a healing variable along with a Healing() method.

That’s it for Abstract classes and Interfaces for the time being, you should certainly expect more in the future!