It’s An Abstract Kind Of Interface: Abstract Classes and Interfaces
Taking advantage of C#’s more advanced features will begin to make more sense from a organizational perspective as you begin looking to make classes more compact and efficient, extracting more and more functionality from multiple classes without creating interlocking dependencies. Some of the tools can help you achieve some semblance of modular code are abstract aclasses and interfaces.
Abstract Classes
These are classes that act as a template for derived classes without the derived classes knowing anything about their structure. It is important to note that Abstract classes cannot be attached to game objects.
What does that mean that classes act as a template? In the example below we have a GoldDistribution abstract class and two unit classses. One is a soldier and the other a mercenary and they override (or replace the contents of Gold Distribution’s version of) CalculateUnitSalary() to substitute their own logic. However they still call UnitIdentification() because there is no reason to replace it.
Here’s the mercenary class.
Finally the soldier class.
So here you can see the basic break down of how Soldier and Mercenary derive from GoldDistribution and then override the virtual method to reject the contents and substitute their own logic. All a virtual void does is allow the deriving class (in this case Soldier and Mercenary) to potentially reject the contents of the base method but it’s possible to still incorporate the base class using the base prefix like below.
Then in Start they both call on UnitIdentification() (since it is still derived from GoldDistribution) without knowing what’s exactly in that class. This is the results of the above code in the console.
Interfaces
These are essentially contracts within your code that the classes that implement interfaces will carry out particular code. What does that mean in practice? Let’s take a look below.
So the structure of an interface is pretty straight forward, they just use properties and methods. Both are empty since they just outline what the derived class has to follow, it’s up to the derived class to figure out the logic. Now let’s see this in other scripts.
Here’s the second script pulling implementing IDamagable.
Like before you can see the same properties and methods in this class as well. Hopefully that clicked for you just there, you have two distinct classes with nothing to do one another implementing a basic level of functionality across your project. This goes doubly when you realize you can implement as many interfaces as you’d like. The final aspect of interfaces is their generic nature, up until now we’ve been implementing hard-coded types into our interfaces. By making the interfaces generic you can pass any and all sorts of data into these interfaces allowing a wide range of possible functionality.
Now let’s see these generic interfaces in action.
There’s no real limitation allow you categorize the interfaces into common function like IShootable, IPickupable, and etc. You can do simple null checks to see if that interface is being utilized and determine if that action is valid. This gives interfaces a powerful way to organize your code into neat modular containers of like functionality. Hopefully this gives you inspiration to come up with your own Abstract classes and Interfaces as you work to making cleaner, clearer, and concise code. Until next time, happy coding.