I am looking at a class in a solution that implements the ISerializable
interface. It has a GetObjectData
method for serialization as required by t
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.