Data serialization architecture, injection on construction vs. on function call

Question

I am creating a data serialization/deserialization mechanism for essentially a persistent storage object. Due to the variety of systems this mechanism could run on, there needs to be a a variable number of "drivers" that could be used to serialize or deserialize the data.

I am having trouble figuring out the appropriate level of abstraction for this system. Primarily, when I construct a "driver", should it have a reference to the object I am storing, or should that object be passed in to the various write functions?

So, let's say I have an some DataAccessLayer which wraps my DataAccessDriver. My DataAccessLayer necessarily contains a reference to some DataObject which it also wraps, and it uses the DataAccessDriver to actually keep some serialized representation of the DataObject.

The question is, should the DataAccessDriver be constructed with a reference to the DataObject, or should I pass in the DataObject for every function call the DataAccessDriver makes?

• J Trana: I'm assuming DataAccessDriver can persist more than one instance of the DataObject? Or is that not the case? I'm just trying to understand if this is closer to say, an ORM or perhaps a configuration file reader/writer.
• MirroredFate: @JTrana That's a large part of my question. I don't know if it's better to make the DataAccessDriver specific to an instance of DataObject or not.

Answer 1

o, let's say I have an some DataAccessLayer which wraps my DataAccessDriver.

I doubt very much there should be such a strong dependency. I vote for serialization subsystem to be completely independent from other things in your application. Note: I vote for serialization to be independent from persistence layer. Serializing an object is one responsibility, saving it anywhere is another one.

My DataAccessLayer necessarily contains a reference to some DataObject which it also wraps, and it uses the DataAccessDriver to actually keep some serialized representation of the DataObject.

What do you mean "wraps"? It created some instance of DataObject, I take it. And then uses serialization to serialize it.

The question is, should the DataAccessDriver be constructed with a reference to the DataObject, or should I pass in the DataObject for every function call the DataAccessDriver makes?

I think this depends on how much configuration serialization needs. If for serialization you need to do some complex setup of the serializer apart from just passing object reference, then it would, probably, be better to pass object to the serializer's constructor, have constructor setup various defaults and then just call serialize(). If serialization logic is as simple as passing an object reference, I vote for one method in the serializer which takes object instance as argument. This case is also slightly better performance-wise because you don't need to create new serializer instance each time you are serializing another object.

• Basilevs: Consider Windows Registry or other tree storage. Can you still claim that serialization is independent of object structure?
• Vladislav Rastrusny: Well, why not? Can you please elaborate? Serialization, surely, takes object structure into account, but it doesn't mean you have to tie serialization to your objects. Almost each language known to be has some serialization libraries developed. They are pretty separate from your objects and in 80% of cases will work without you having to setup anything. Even that setup usually is limited to providing __sleep/__wakeup-like functions on your objects.