Is this bad OOP design for a simulation involving interfaces?

Question

I am designing my own little OOP program to simulate Vampires, Wolves, Humans and Trucks and am trying to implement my own limited understanding of Interfaces.

(I am still abstracting here and have no code implementation yet, so it's rather a question of OOP design...I think!)

Am I right in looking for 'common behaviour' between these classes and implementing them as interfaces?

For example, Vampires and Wolves bite...so should I have a bite interface?

public class Vampire : Villain, IBite, IMove, IAttack

Likewise for Trucks...

public class Truck : Vehicle, IMove

And for Humans...

public class Man : Human, IMove, IDead

Is my thinking right here? (Appreciate your help)

Answer 1

In general you want to have interfaces for common characteristics of your clasess.

I semi-agree with @Robert Harvey in the comments, who said that usually interfaces represent more abstract features of classes. Nevertheless, I find starting from more concrete examples a good way of starting to think abstract.

While your example is technically correct (i.e. yes, both vampires and wolves bite, so you can have an interface for that), there is a question of relevance. Each object has thousands of characteristics (e.g. animals may have fur, can swim, can climb trees, and so on). Will you make an interface for all of them? Very less likely.

You usually want interfaces for things that make sense to be grouped in an application as a whole. For example, if you are building a game, you can have an array of IMove objects and update their position. If you don't want to do that, having the IMove interface is pretty useless.

The point is, don't over engineer. You need to think about how are you going to use that interface, and 2 classes having a method in common is not a good enough reason to create an interface.

Answer 2

Looks like you're creating a bunch of single method interfaces. This is fine on the face of it but keep in mind that interfaces are not owned by the class/es that implement them. They are owned by the clients that use them. The clients decide if something needs to be something that can move and attack.

If I have a Combat class with a fight() method, that method likely has a need to call both move() and attack() on the same object. That strongly suggests a need for an ICombatant interface that fight() can call move() and attack() through. This is cleaner than fight() taking an IAttack object and casting it to IMove to see if it can also move.

That doesn't mean you can't also have IMove IAttack interfaces. I just hope you aren't making them without some client needing them. Conversely, if no client ever needs to make an object both move and attack then ICombatant isn't needed.

This simple way of looking at interfaces is often lost because people like following examples. The first interfaces we're exposed to are in libraries. Unfortunately, libraries have no idea what their clients are. So they can only guess at their clients needs. Not the best example to follow.

Answer 3

Consider whether it will be common to have collections of objects with different combinations of abilities, and whether code might want to perform an action upon those items, within a collection, that support it. If so, and if there would be a sensible "default behavior" for objects which don't have useful support for some action, it may be helpful to have interfaces implemented by a wide range of classes, not just those that can behave usefully.

For example, suppose only a few kinds of creature can have Woozles, and one wants such creatures to have a NumerOfWoozles property. If such a property were in an interface that were only implemented by creatures that can have Woozles, then code which wanted to find the total number of Woozles held by a collection of creatures of mixed types would have to say something like:

int total = 0;
foreach (object it in creatures)
{
   IWoozleCountable w = trycast(it, IWoozleCountable);
   if (w != null) total += w.WoozleCount;
}

If, however, WoozleCount were a member of Creature/ICreature, even though few subtypes would override Creature's default WoozleCount implementation that always returns zero, the code could be simplified to:

int total = 0;
foreach (ICreature it in creatures)
   total += it.WoozleCount;

While some people might chafe at the idea of having every Creature implement a WoozleCount property that's really only useful for a few subtypes, the property would be meaningful for all types, whether or not it would be useful with items known to be of those types, and I would regard the "kitchen sink" interface as being less of a code smell than the trycast operator.