Information Technology Reference
In-Depth Information
serialization properly, you create more work for all developers who intend
to use your types as a member or base class. When your type does not sup-
port serialization, they must work around it, adding their own imple-
mentation of a standard feature. It's unlikely that clients could properly
implement serialization for your types without access to private details in
your types. If you don't supply serialization, it's difficult or impossible for
users of your class to add it.
Instead, prefer adding serialization to your types when practical. It should
be practical for all types that do not represent UI widgets, windows, or
forms. The extra perceived work is no excuse. .NET serialization support
is so simple that you don't have any reasonable excuse not to support it. In
many cases, adding the Serializable attribute is enough:
[
Serializable
]
public class
MyType
{
private string
label;
private int
value;
}
Adding the Serializable attribute works because all the members of this
type are serializable:
string
and
int
both support .NET serialization. The
reason it's important for you to support serialization wherever possible
becomes obvious when you add another field of a custom type:
[
Serializable
]
public class
MyType
{
private string
label;
private int
value;
private
OtherClass
otherThing;
}
The Serializable attribute works here only if the OtherClass type supports
.NET serialization. If OtherClass is not serializable, you get a runtime error
and you have to write your own code to serialize MyType and the
OtherClass object inside it. That's just not possible without extensive
knowledge of the internals defined in OtherClass.
.NET serialization saves all member variables in your object to the output
stream. In addition, the .NET serialization code supports arbitrary object
