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?
2
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.
2