I have an existing application that uses CArchive to serialize a object structure to a file. I am wondering if can replace the usage of CArchive with some custom class to write to a database the same way that things are serialized. Before I go about figuring if this is doable I was wondering if other people have done the same- what is the best approach to this problem? I would like to be able to create a drop in replacement for the usage of CArchive so that the existing object structure would simply read/write to/from a database rather than a serialized file. Is it as simple as overwriting the Serialize method for each class?
Short answer: forget it.
Longer answer:
CArchive doesn't have a single virtual member. Even it's destructor isn't virtual, which means you're not supposed to derive from that class (C# programmers say sealed).
There's only one possibility that I can think of to customize CArchive's work (and without rewriting the whole serialization code in CDocument): Construct your CArchive object by passing it a pointer to CFile derived class that would handle the data connection for you.
From there on, how you control your database by simply overriding CFile's Read() and Write() is beyond my imagination :-(
Related
I'm trying to do some polymorphic deseralization of JSON using Jackson, however the list of subclasses is unknown at compile time, so I can't use a #JsonSubtype annotation on the base class.
Instead I want to use a TypeIdResolver class to perform the conversion to and from a property value.
The list of possible subclasses I might encounter will be dynamic, but they are all registered at run time with a registry. So I would appear to need my TypeIdResolver object to have a reference to that registry class. It has to operate in what is essentially a dependency injection environment (i.e I can't have a singleton class that the TypeIdResolver consults), so I think I need to inject the registry class into the TypeIdResolver. The kind of code I think I want write is:
ObjectMapper mapper = new ObjectMapper();
mapper.something(new MyTypeIdResolver(subclassRegistry));
mapper.readValue(...)
However, I can't find a way of doing the bit in the middle. The only methods I can find use java annotations to specify what the TypeIdResolver is going to be.
This question Is there a way to specify #JsonTypeIdResolver on mapper config instead of annotation? is the same, though the motivation is different, and the answer is to use an annotation mixin, which won't work here.
SimpleModule has method registerSubtypes(), with which you can register subtypes. If only passing Classes, simple class name is used as type id, but you can also pass NamedType to define type id to use for sub-class.
So, if you do know full set, just build SimpleModule, register that to mapper.
Otherwise if this does not work you may need to resort to just sharing data via static singleton instance (if applicable), or even ThreadLocal.
Note that in the end what I did was abandon Jackson and write my own much simpler framework based on javax.json that just did the kinds of serialisation I wanted in a much more straightforward fashion. I was only dealing with simple DTO (data transfer object) classes, so it was just much simpler to write my own simple framework.
Say I have a class, Master, that starts up my program, and I have another class, TerminalIO, that has functions and data for talking to stdin and stdout. I then instantiate a Master object from main().
In code within the methods of TerminalIO, how would I access the properties and functions of Master?
The reason I'm asking about this is because my program needs to store some shared data (both enums and regular variables), and I was wanting to know of an efficient way to do that. I'm not so sure this is the best way, but it's certainly better than toying with the package keyword and trying to store "global" data at module level or whathaveyou.
I think it's worth noting that I will have many other objects that also want access to this shared data, so a simple reference may not be the best of ideas.
You will have to get a reference to Master inside your TerminalIO.
There are a couple of ways you could use:
Have Master be a singleton, so there is only one instance which you can access with Master.instance, so you'll have something like Master.instance.masterProperty.
Having a TerminalIO factory method in Master which constructs a TerminalIO and passes a Master reference to the constructor.
I just want advice on whether I could improve structure around a particular class which handles all disk access functions
The structure of my program is that I have a class called Disk which gets data from flatfiles and databases on a, you guessed it, hard disk drive. I have functions like
LoadTextFileToStringList,
WriteStringToTextFile,
DeleteLineInTextFile
etc
which are kind of "generic methods"
In the same class I also have some more specific methods such as GetXFromDisk where X might be a particular field in a database table/query.
Should I separate out the generic methods from the specialised. Should I make another class which inherits the generic methods. At the moment my class is static as there is no need to have an internal state of the class.
I'm not really OOPing am I?
Thanks
Thomas
If you are using only static static functions you are not really OOPing as you said. It is writing procedural code in OO language.
You should look to create classes which represent objects in your problem domain like File and TextFile. These classes should have operations like DeleteLine, WriteLIne, Load etc.
Also, in which ever language you are programming, it is likely to have a good File IO library. Try to use that in your code as much as possible. If needed just write wrappers over the library classes to provide some additional functionality.
Well, what you seem to have in your code is a Utilities class where you bundle in all the file methods.
This could indicate some design issue but IMHO it is ok, since it is common to have utility classes in OOP designs.
It haves the benefit of being able to add extra methods or modify existing ones easy since you will not have any derived classes extending the Utility class to be affected.
For example java has static methods everywhere. E.g. Collection class.
I would suggest to have the class's contructor be private and have the naming such that is obvious that this is a Utilities class.
how does Serialization of objects works? How object got deserialized and a instance is created from serialized date without a call to any constructor?
I've kept this answer language agnostic since a language wasn't given.
When the object is serialized, all the require information to rebuild it is encoded in way which can be retrieved. This typically includes the type of the object, as well as the value of all the instance variables.
When the object is deserialized, an area in memory of the correct size is allocated and is populated using the serialized information such that the new object is identical to the serialized one.
The running program can then refer to this new object in memory without having to actually call the constructor.
There are lots of little details which this doesn't explain, but this is the general idea of serialization/deserialization.
Are you talking about Java? If so, serialization is an extralingual object creation mechanism. It's a backdoor that uses native code to create the object without calling any constructors. Therefore, when designing a class for serializability, you need to make sure that a class created through deserialization maintains the same invariants (key fields being initialized) as you would through the constructor path. A third way to create objects in Java is through cloning, and similar issues apply.
Cloning and serialization don't interact well with the use of final fields if you need to set the value of that field to something different than what is returned by clone or the deserialization process.
Josh Bloch's "Effective Java" has some chapters that explain these issues in more depth.
(this answer may apply to other languages too, but I've only used serialization in Java)
Regarding .NET: this isn't a definitive or textbook answer, and I might be all-out wrong...
.NET Serialization needs to be seperated out into Binary vs. others (XML or an XML derivitave typically). Binary serialization is mostly a black-box to me, but it allows the object to be serialized and restored in their current state. XML serialization typically only serialized the public fields/properties of an object, unless overriden by adding a custom ISerializable implementation.
In the case of XML serialization I believe .NET uses Reflection to determine which fields and properties get converted to their equivalent Elements. Adding an [XMLSerializable] attribute will implement a default behavior which can be adjusted by applying other attributes at the field level (such as [XMLAttribute]).
The metadata (which Reflection depends on) stores all the object members as well as their attributes and addresses, which allows the serializer to determine how it should build the output.
I recently had to write some code which parsed a file to set data in an object. As there were several objects and corresponding files involved here, I decided to separate the parsing code out.
So I then had one class for parsing the files, CommandFileParser, and two classes per file/object type: one for the actual object itself and one for the possible commands that may be used to set the data in the object. e.g. VectorDrawing and VectorDrawingCommands. The latter's methods would be called by CommandFileParser using reflection as it found them in the input file, and applied data to the former.
But to me this seems like a really messy way of doing it. I ended up repeating loads of boilerplate code doing stuff like dataobject.value = value in all the of -Commands classes. And I don't like having an auxillary class per main data class just to set the data.
Can anyone suggest any ideas for cleaner and more appropriately OO ways of doing this?
"I ended up repeating loads of boilerplate code doing stuff like dataobject.value = value."
The assignment statement isn't really "boilerplate". It's the most important statement you have; the fact that there are many means you're doing lots of important things.
However, other "boilerplate" could be anything. Could you provide examples of the specific boilerplate you object to?
If all of your commands just involve direct assignments, perhaps you don't need the command objects. Can you directly do reflection on the objects themselves and get rid of the command objects entirely?
Another possibility is that you have two classes of commands: One is directly implemented by the object, e.g., simple property setting, and the other that is implemented by external command objects, e.g., for commands that need to do calculations or set multiple properties. You do the same reflection as before, but just check two objects.
BTW, I like the idea of using reflection to look for commands. It makes it incredibly easy to add new commands.
I don't know about VB.Net, but in all OO language with which I'm familiar, the normal approach is for a mutable object to contain the methods that set its own attributes' values, rather than putting that work into a second class.
Is there some reason why you wouldn't put the methods in your current VectorDrawingCommands class directly in VectorDrawing instead, and eliminate VectorDrawingCommands completely?
Maybe you want each Class to inherit the CommandFileParser instead of separating it out.
Why couldn't you just use reflection to set the values of the fields or properties directly and remove the entire concept of the -Commands classes?