Best way of organising load/save functions in terms of static/non-static

Question

I have a class which defines a historical extraction on a database:

class ExtractionConfiguration  
{  
    string ExtractionName;  
    time ExtractionStartTime;  
    time ExtractionEndTime;

    // Should these functions be static/non-static?
    // The load/save path is a function of ExtractionName
    void SaveConfigruation();
    void LoadConfiguration();
}  

These ExtractionConfigurations need to be saved to/loaded from disk. What is the best way of organising the save/load functions in terms of static/non-static? To me, it is clear that SaveConfiguration() should be a member function. However with LoadConfiguration(), does it make more sense to call

ExtractionConfiguration newExtraction;  
newExtraction.LoadConfiguration();

and have a temporary empty instance or make the load function static

static ExtractionConfiguration LoadConfiguration(string filename);

and just call

ExtractionConfiguration newExtraction = ExtractionConfiguration::LoadConfiguration(filename);

which feels neater to me, but breaks the 'symmetry' of the load/save mechanism (is this even a meaningful/worthwhile consideration?).

I suppose asking for the 'best' answer is somewhat naive. I am really trying to get a better understanding of the issues involved here.

P.S. This is my first question on SO, so if I have not presented it correctly, please let me know and I will try and make the problem clearer.

Answer 1

You should consider using Boost.Serialization style serialization function that avoids having separate functions for saving and loading (even if you don't use the library itself).

In this approach you can pass the function any type of object that has operator&, to perform an operation on all the member variables. One such object might save the data to a file, another might load from a file, third might print the data on console (for debugging, etc).

If you wish to keep separate functions, having them as non-static members might be a better option. For the saving function this is obvious, but loading is a different matter because there you need to construct the object. However, quite commonly loading is done by default-constructing and then calling the load non-static member function, for symmetry reasons, I guess.

Having the loading as a function that returns a new object seems better in some ways, but then you need to decide how it returns the object. Is it allocated by new, or simply returned by value? Returning by value requires the object to be copyable and returning a pointer mandates the resource management scheme (cannot just store the object on stack).