This is called a "marker interface." Sometimes they're used to indicate that a class is meant for a certain purpose. It's not a desirable practice.
While I have used marker interfaces, here's an illustration of the problem they create. Suppose I have a List<ICube>
. Perhaps I receive it as a method argument.
public interface ICube {} // It's empty!
public void DoSomethingWithTheseCubes(List<ICube> cubes)
{
foreach(var cube in cubes)
{
// what do I do with this cube?
}
}
You can see where I get stuck. ICube
is just a marker interface, so it has no methods or properties of its own. I can't do anything with it. That's likely to result in me casting each cube to some other type so I can do something with it.
public void DoSomethingWithTheseCubes(List<ICube> cubes)
{
foreach(var cube in cubes)
{
(SomeOtherType)cube.DoSomething();
}
}
But if I cast it I'm inviting a runtime error because I may not know for sure what the actual runtime type of each object is. If I know what the runtime type is, then I just should do this:
public void DoSomethingWithTheseCubes(List<SomeOtherType> things)
{
foreach(var thing in things)
{
thing.DoSomething();
}
}
We're not absolutely certain to have that problem, but using a marker interface invites it. It's using an interface for something other than its intended purpose. It's more like an attribute or even a comment.
An interface has two uses that work together: First, it describes the members that a class implements. Second, it allows us to cast a class that implements an interface as that interface. Marker interfaces do neither. They allow us to cast an object as a type with no members. That's useless at best, and at worst it's harmful because it leads to even more questionable casting.