Question

I am looking at a class in a solution that implements the ISerializable interface. It has a GetObjectData method for serialization as required by the interface. There is not any custom serialization happening here, it is simply populating the SerializationInfo object with the names of the properties of the class and their values.

[Serializable]
public class PersonName :ISerializable
{
    [DataMember]
    public string NamePrefix { get; set; }
    [DataMember]
    public string GivenName { get; set; }
    [DataMember]
    public string SurName { get; set; }

    public PersonName(string givenName, string surName, string namePrefix)
    {
        GivenName = givenName;
        SurName = surName;
        NamePrefix = namePrefix;
    }

    public PersonName()
    {
    }

    #region ISerializable Members

    public void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        info.AddValue("NamePrefix",NamePrefix);
        info.AddValue("GivenName",GivenName);
        info.AddValue("SurName",SurName);
    }
}

From the documentation I’ve read so far, as I understand it, this is what would happen anyway by the class being marked with the [Serializable] attribute, and as you can see the class does not have a deserialization constructor, which is why I’m looking at it to begin with. From what I can tell, rather than needing to add the deserialization constructor to the class, the class really doesn’t need to implement the ISerializable interface in the first place. Is that correct?

Answer 1

It’s pretty pointless.

It could be justified if it had once implemented ISerializable for a better reason, and implementation changes meant that it was no longer as useful. It could be a breaking change to stop implementing it.

If they’d implemented it with an explicit implementation (void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context) rather than public void GetObjectData(SerializationInfo info, StreamingContext context) and had the constructor that took SerializationInfo and StreamingContext private, then it’d be a less damaging change – still technically a breaking change but much less likely to actually break any real uses. This in itself is a reason for having that constructor private.

It must though be at least protected if the class isn’t sealed, and derived classes must use it if they are to also be serialisable. In this case it’s totally going to be a breaking change to stop using it as all derived classes would then be broken.

It would likewise be breaking change if you didn’t implement it, and then started doing so, and had classes derived from it. This could be a justification for pre-empting the possibility, though to be honest I’d see that as a major failure of the YAGNI principle unless there was a very very good reason to suspect it would become useful. (Generally if you were going to add something that would make it necessary you could wrap whatever features required it in another class, implement it on that, and have a member of that type, so the existing class can still be serialised without it).

Edit: The “must” above is the “must” of “you must do this or there are bad implications” rather than the “must” of “you must do this or it won’t compile”. Of course, the former are worse than the latter because you can sometimes fail to do them.