14

I'm a bit confused about

The purpose of Marker Interface Vs Attributes.

Their purpose looks same to me(Pardon me if I'm wrong).

Can anyone please explain how do they differ in purpose?

Manish
  • 6,106
  • 19
  • 64
  • 90
  • Attributes? Do you mean annotations? – user207421 Oct 13 '10 at 12:50
  • 2
    @EJP, in .net those are called attributes. But the Java guys had to find a different name for the same thing when they finally also implemented them after telling everyone a long time that this was nonsense... – Lucero Oct 13 '10 at 12:52
  • @EJP: Attributes in .Net: http://msdn.microsoft.com/en-us/library/aa288454(VS.71).aspx – Manish Oct 13 '10 at 12:53
  • possible duplicate of [What is the purpose of a marker interface?](http://stackoverflow.com/questions/1023068/what-is-the-purpose-of-a-marker-interface) – Lucero Oct 13 '10 at 12:56

4 Answers4

16

Here are some advantages of both.

Marker interfaces:

  • are a bit easier to check for using dynamic type checks (´obj is IMarker´);
  • allow for functional and data extensibility in the future (i.e. turning a “marker” interface into a “full” interface that actually declares some members);
  • can be used in generic type constraints;

On the other hand, attributes:

  • provide a clearer separation of metadata;
  • allow for specifying additional information via their constructors or properties;
  • allow for multiple application to an entity;
  • are general-purpose in terms of applicability to different kinds of entities, not just classes;

It heavily depends on the particular application's architecture and design whether it's appropriate to use a marker interface or an attribute in a particular case.

Ondrej Tucny
  • 27,626
  • 6
  • 70
  • 90
9

Some years ago, in the pre Java 5 era, Java didn't support attributes. Therefore, to "tag" a class or an interface so that they could be checked at runtime, you would use marker interfaces, which is basically an empty interface but you can still check if an instance can be casted to this interface.

In .NET, marker interfaces should not be used except for special use cases (such as allowing the use of extension methods), because attributes provide a better way to mark classes (and lots more) with metainformation. The same goes for Java 5 and newer, where annotations were introduced and should be used instead.

Lucero
  • 59,176
  • 9
  • 122
  • 152
  • I partly disagree. Marker Interfaces are still usefull and in use today. For example ICommand is a Marker Interface as is IDisposable, INotifyPropertyChanged and so on... and they are definitly not empty interfaces. But of course attributes are the prefered choice in .NET for adding meta data. – RonaldV Oct 13 '10 at 13:02
  • 10
    @RonaldV: IMO, marker interfaces are empty *by definition*. Therefore, if an interface is not empty, then it follows that must not be a marker interface. I would definitely say that none of the interfaces you mentioned are marker interfaces at all. This is particularly true in the case of IDisposable, which has methods that are called by language primitives. – Sean Reilly Oct 13 '10 at 13:37
  • Looked it up and yup you're correct. It seems like a lot of people are using the term very loosely and incorrectly. – RonaldV Oct 13 '10 at 14:09
  • 4
    I disagree that attributes are "better" than marker interfaces. Attributes are run-time accessible metadata. Reading them is a pain and requires reflection, which is inherently slow and not-type-safe compared to `is`; you also can't create a generic constraint like `where T : [Serializable]`, but you can do `where T : ISerializable`. – Michael Edenfield Apr 10 '12 at 15:19
  • Interfaces are inherited; attributes aren't. In cases where any class derived from one advertising a feature should be compelled to offer that same feature, a marker interface will accomplish that. In cases where derivatives of a class should have the option to implement a feature or not as they see fit, attributes might be better, though an interface with a reflexive generic type parameter might also be useful. – supercat Jul 21 '15 at 16:59
  • For example, an interface `IProduceableFromString` might specify that all legitimate implementations must promise that type `T` has a method `public static T ProduceFromString(string specs)`. If `Foo` legitimately implements that interface, then `DerivedFoo:Foo` would implement `IProduceableFromString`, but that would be a promise about `Foo` (which, if `Foo` is legitimate, it will uphold); the normal usage of the interface, though, would be as a constraint `where T:IProduceableFromString`, which `Foo` would satisfy and `DerivedFoo` would not. – supercat Jul 21 '15 at 17:14
9

If you can use it, an Attribute is preferred.

But there are a few features related to static typing only an interface can offer:

  1. You can add extension methods to it
  2. You can use it as a generic constraint
CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
7

As an aside, it is much quicker to check for an interface, as the CLI is designed for that and has opcodes for it (as does c#: is/as).

Checking attributes requires reflection; much slower.

Looking though the other answers most points are covered, but also: attributes are much more limited in terms of what values you can pass into them; mainly primitives and string.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • 2
    If reflection for attributes should become a performance problem one can easily use a dictionary with the Type as key as a cache. So the performance benefit alone usually shouldn't make one use the interface instead of an Attribute. – CodesInChaos Oct 13 '10 at 13:48
  • 2
    Even dictionary access is very slow compared to a simple RTTI check – Marc Gravell Oct 25 '10 at 08:39