25

Possible Duplicate:
What is the purpose of a marker interface?

Is it bad practice to create a completely empty interface such as:

public interface ISomething
{
}

There is a case where I would like to treat certain objects differently than others, but I don't require any new behavior.

Community
  • 1
  • 1
Erix
  • 7,059
  • 2
  • 35
  • 61
  • I'm marking as duplicate of http://stackoverflow.com/questions/1023068/what-is-the-purpose-of-a-marker-interface because it effectively answers this question. – spender Jul 22 '10 at 16:14
  • never heard of the term 'marker interface' before. So I didn't find that while searching. – Erix Jul 22 '10 at 16:16
  • @SP - I would take Scott's suggestion to heart in that linked answer, imo, it's the root of some vile evil. – Marc Jul 22 '10 at 16:19

6 Answers6

26

I personally think that empty interfaces are not a good thing.

Interfaces are meant to describe behavioral contracts. An empty interface doesn't describe any behavior - you're not defining any form of contract here.

The design guidelines for interfaces specifically says:

Avoid using marker interfaces (interfaces with no members).

Custom attributes provide a way to mark a type. For more information about custom attributes, see Writing Custom Attributes. Custom attributes are preferred when you can defer checking for the attribute until the code is executing. If your scenario requires compile-time checking, you cannot comply with this guideline.

Community
  • 1
  • 1
Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
12

Have you considered using an attribute instead of an interface? That would usually be my approach. Admittedly it's slightly harder to test for the presence of an attribute than whether an object implements an interface, but it feels like a better fit in general.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 5
    But attributes don't enable extension methods. – Ben Voigt Jul 22 '10 at 16:55
  • @BenVoigt Neither do they prevent you from passing the wrong object to a method, for example: IThingA : IThing and IThingB : IThing. The two interfaces represent the same thing in concept with two completely incompatible structures. I would much rather accept an empty IThing than object, relying on run-time attribute tests. – Daniel Apr 09 '20 at 16:33
  • @Daniel: That's an LSP violation which is not relevant to the question or answer here. – Ben Voigt Apr 09 '20 at 18:17
  • @BenVoigt You can substitute ThingA or ThingB for Thing any day of the week, and LSP is preserved. You can't break behavior that doesn't exist, and an empty interface has none. On relevance, using the type system to identify objects of interest at compile time is right on the money with this topic--arguably moreso than extension methods. – Daniel Apr 09 '20 at 21:14
  • @Daniel: You said they are incompatible. You cannot substitute things that are incompatible. An "empty" interface is not lacking in behavior, all it means is that the interface contract is not expressible in the language. But there still is a contract which all implementers much adhere to. LSP is about contracts, not call signatures. – Ben Voigt Apr 10 '20 at 14:46
  • @BenVoigt I think you misunderstood my comment. The colons were meant to signify interface inheritance from the empty interface. The structures (implementations, signatures, etc) of IThingA and IThingB are incompatible, but they are both compatible with empty interface IThing from which they derive. LSP is not concerned with the relationship between peers in an inheritance hierarchy, and in this example, the empty parent interface can be replaced with any of its children without consequence as its derivatives are strictly additive. – Daniel Apr 12 '20 at 03:01
2

I'd say an Attribute is better but there are examples in the .Net framework of empty interfaces (e.g. INamingContainer - http://msdn.microsoft.com/en-us/library/system.web.ui.inamingcontainer.aspx). Ive always wondered why that was done in that way - anybody know?

barrylloyd
  • 1,599
  • 1
  • 11
  • 18
2

It seems to me that implementing a marker interface and attaching an attribute with no parameters differ only in syntax, but the former is more straight forward to use with run time type information.

I am not prepared to make a hard and fast rule to never use marker interfaces, personally, but I can see the potential downfall if they are used for more than merely "marking" - in which case attributes might be a better fit.

That said, if I compare the first time I came across an empty interface (I remember it was definately Java circa 2000) with the first time I came across an attribute (C# web services) - I was able to deduce the purpose of the one but the other forced me into a learning mode...

Aaron Anodide
  • 16,906
  • 15
  • 62
  • 121
1

I agree with everyone here. I think if I were given code to maintain and saw a class with an interface that had no properties or methods I would be very confused.

In an asp.net mvc app that I worked on recently I had a core operation (tracking code) I wanted done on almost every request (but not on say and ajax request or an admin page). I added the operation to a base controller and executed it in the ExecuteCore method. For the few situations I didn't want it to run I set a flag in the derived controller not to run it.

This isn't as clean and elegant as an attribute but it is much simpler to implement.

Of course this won't help if you want to create generic operations for all the derived classes. But in such a case there would have to be some things in common about the objects (say a common property) which would mean the interface wouldn't be empty.

Sruly
  • 10,200
  • 6
  • 34
  • 39
0

I don't do that but I see no good reason against it. I often create a base class for generic types so I can contain a collection of generic items. An interface might be a cleaner way to do that, but I would usually find something to put in the base class so the interface solution wouldn't work for that.

I guess you could think of it as an abstract base class?

Nate Zaugg
  • 4,202
  • 2
  • 36
  • 53