Peter Dimov wrote: [...]
If your serialization methods
- allow creation of objects whose invariants do not hold, or
Of course. This is analogous to writing a buggy copy constructor.
- expose implementation details in the external representation,
This is more tricky: you may want to serialize an object which is in a state that in normal circumstances is not the direct outcome of construction, but rather is the result of some activity. How can you manage that? Either you provide a special purpose constructor or you open up the object's internal state. I would say that while a "serializable" class should be independent of the serialization machinery, the provision of a specific serialization interface must be explicitly considered. This interface is indeed part of the class. Cheers, Nicola Musatti