Interface without any members - bad practice? [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate:

What is the pur开发者_如何学Pythonpose 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.

---

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.

---

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.

---

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?

---

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...

---

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.

---

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?