I want to spawn two types of enemies in rows (think Galaga), how should I set up my classes inheritance wise?

Question

I want to make a game similar to galaga in xna using C#. I have two types of enemies (behavior and sprite are different, as well as sound effects), and I want each to have their own rows. I was earlier using arrays to generate enemies on screen, but apparently this isn't a good approach and was told I should use lists instead. Now, I was thinking there could be a few of ways of creating the enemy classes themselves. One was using inheritance, with a base class of Enemy, and then two other classes that inherit from Enemy but have their own behavior and sprite. Another way of doing this would be to create an enemy interface. And one other way of setting this up would be to use structs. I think using interface would be more time consuming compared to the other two, but I could be wrong (if I am, let me know). The other two I am not sure about though. Technically, I believe they both use classes, just one uses structs. What would be the better way of doing this, inheriting from an enemy class, or using an enemy struct?

Answer 1

Considering a simple scenario, creating the Enemy class and then using inheritance is the way to go.

If you need a more complex logical tree to add specific methods to entities that don't belong to the same tree then start using Interfaces. For example, if there is an "Enemy" tree and an "Ally" tree and you want some kind of same behaviour for enemy Type1 (inherits from Enemy) and ally Type2 (inherits from Ally) when they die, then consider using an interface for that.

Anyway and just as an example, the use of an Interface could be justified when you need to manage Lists of objects that are tagged with that interface to call specific methods (entities that for example "ExplodeWhenDying"). If you don't need to manage those kind of lists, then just use methods on a common parent class (for example "Entity" (Enemy and Ally inherit from Entity) and overwrite those methods (Explode()).

Interfaces are better suited to situations in which your program requires many possibly unrelated object types to provide certain functionality which i guess is not the case here.

Answer 2

The longer I code up solutions the more I like the concept of "Favor Composition over inheritance". It doesn't mean reject inheritance but many times in my past I over-used inheritance. The advantages to composition are that the lowest object in the hierarchy is always expandable, there is NEVER any name confusion and it leads to better unit testing.

But what is composition? It's simply the ability to contain some other object within your parent object. I typically use property getters and setters to expose the object like example below. All cars have wheels and engines and color and could be inherted, but they are NOT a type of any of those, so it's better to compose them or "inject" the traits... This is composition and shows concrete classes (not interfaces). Interfaces are better but you don't have to do them.

public class ComposeACar
{
    public ComposeACar(Wheels theWheels, Engine theEngine, Color theColor)
    {
        MyWheels = theWheels;
        MyEngine = theEngine;
        MyColor = theColor;
    }
    public Wheels MyWheels { get; set; }
    public Engine MyEngine { get; set; }
    public Color MyColor { get; set; }
}


public class Wheels {
    public string size { get; set; }
    public decimal price { get; set; }
    public string Manufacturer { get; set; }
}
/// <summary>
/// Same here for the next two class examples
/// </summary>
public class Engine {}
public class Color {};

public class BuildACar {

    public BuildACar()
    {
        var wheels = new Wheels { Manufacturer = "GoodYear", size = "17", price = 195.00M };
        var engien = new Engine();
        var color = new Color();
        var newCar = new ComposeACar(wheels,engien,color);
    }
}