Alex Rivera | Logout

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

Asked 2010-04-19T13:57:40.190
20

This might be a stupid question but I'll 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.

Edit
Report

3 Answers

7

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.

answered 2010-04-19T15:49:06.183
2

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.

answered 2010-04-19T14:54:57.680
1

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.

answered 2010-04-19T14:09:08.463

Your Answer