Difference between implementing an interface and applying an attribute in C#

Question

This might be a stupid question but Ill ask anyway,

I was reading "OOP Demystified: A Self-Teaching Guide by Jim Keogh and Mario Giannini" chapter 11 which covers interfaces. The examples in this book are C++.

I noticed that C++ uses ISerializable to make a class serializable which you would implement where as in C# you just attribute the class with the [Serializable] attribute.

What is the key difference here? Is it that with an interface you must provide the implementation where as if you attribute something the compiler will work out the implementation for you?

I guess that with the [Serializable] attribute the .Net framework uses reflection to make the serialized object from the actual object.

That said is it possible in that case to have an [Disposable] attribute or using my theory above the framework wont know how to actually dispose of an object hence you have to do it yourself?

Would be grateful for a clarification.

Thanks.

Answer 1

Most attributes will only be checked at runtime. There are some checked at compile time (see conditional attribute as mentioned below). For the most part, with an attribute you have to use reflection to see if an object posses it and make your decision on what to do from there.

An interface is a compiler implementation. With an interface, you can require that parameters implement it for methods etc.

Attributes: http://msdn.microsoft.com/en-us/library/z0w1kczw.aspx

Interfaces: http://msdn.microsoft.com/en-us/library/ms173156.aspx

Answer 2

I think you missed the fact that .NET (C#) also has an ISerializable interface:

[Serializable]
class Foo : ISerializable
{
}

The attribute is 'custom meta data', the interface is a language feature.

Answer 3

I think this is because traditionally certain properties have been marked as serializable or not serializable and this means that it makes more sense to also have the attribute at the class level.

There is a slight performance penalty checking the class for an attribute at runtime vs checking the type at compile time.

Answer 4

A long time ago in a galaxy far, far away... There were no Attributes or compiler support for class metadata, so the developers tried to implement their own. One of the methods our ancestors worked out were to declare Marker Interfaces .

So, to answer your question: custom attributes are an "evolution" of marker interfaces. You can use both. But note that, if you want to enforce that your object implement specific methods, you are using an interface, plain and simple. That's how IDisposable works, it forces you to implement a method named Dispose(). [Serializable] (and probably ISerializable on your C++ example) does not force you to implement anything, as the runtime will just read that declaration and do its task (i.e., serialize the object).

Note that C# also have a ISerializable interface... It is meant to let you write your custom serialization code, which will then be called by the runtime. Note that it is NOT a marker interface nor replacement for the [Serializable] attribute, as you still need to mark your class with the attribute for the serialization to work.

Answer 5

You are reading too much in the attribute. [Serializable] does very little. It is used by binary serialization, as implemented by the BinaryFormatter class. That class has very powerful capabilities, it can create an instance of a class without using public properties of the class. It directly assigns values to fields that are marked private, completely bypassing the normal access rules.

You have to explicitly give BinaryFormatter the right to do so, essentially acknowledging that an object of your class can be deserialized without problems. You do so by applying the [Serializable] attribute. BinaryFormatter merely checks if it is present. That's all.

Answer 6

Attributes generally provide additional metadata about a type or member; there are significant limitations about what is allowed (const values etc), and Eric Lippert provided some thoughts on the difference between interfaces and properties which might be illuminating.

There are some other aspects of interfaces:

• they can have multiple members
• behind an interface lies some implementation (this is critical)
• you can use the interface for abstraction (not so much the attribute)

However; at the downside, once a type implements an interface all subtypes also implement that interface via inheritance. Contrast attributes, which can be inherited but don't want to be.

Just because Foo is serializable, that does not mean that Bar (:Foo) should necessarily be serializable; so it is nice to be able to define that at each level - although actually I don't think that BinaryFormatter should be a key part of mots serialization code (I'll bite my tongue, though).

Actually, if you check the IL you'll see that [Serializable] doesn't actually get written as an attribute - it is a CLI flag instead (some compiler magic). But that doesn't change the fact.

If all you need to do is express metadata (facts about the type/member), attributes are ideal. If you need to express a behaviour / API, then an interface.