C++ constructor and good style of programming

[Horsey]

Hi,

I have a class in my project, which is a dictionary. It holds all the declination and stuff for my language. Before I start to use it in program, it must be loaded with data. The nouns, verbs, adverbs and pronouns are loaded from dictionary files into memory, then the object is ready to be used.

For me, the most clear solution is to keep importing data from these four files in object's constructor (precisely: in methods called from constructor; one method per file). This way I know that object after being created is ready to work and I don't have to create a method like "initialise()", which should be explicitly called.

Is this solution following the good programming style rules? I find a constructor as a method which prepares an object to be useful, not just to be safe (like initialising variables, especially pointers).

Big thanks in advance for any help.

[Lindley]

The question is what you'll do if loading fails. Normal methods can return a status code; a constructor has only two options: set some internal state indicating the object is invalid, or throw an exception.

[D_Drmmr]

For me, the most clear solution is to keep importing data from these four files in object's constructor (precisely: in methods called from constructor; one method per file). This way I know that object after being created is ready to work and I don't have to create a method like "initialise()", which should be explicitly called.

Is this solution following the good programming style rules? I find a constructor as a method which prepares an object to be useful, not just to be safe (like initialising variables, especially pointers).

It's good to be able to fully initialize an object in a constructor, cause sometimes this allows for better code than two-stage initialization. However, not being able to default construct an object or not being able to change an object after construction is a severe limitation.
- What if you want to load different files into a dictionary, e.g. to separate predefined and user defined words?
- What if you want to load the dictionary in a worker thread to keep your application responsive? If the dictionary is initialized in the constructor, you'll probably need to keep a pointer and dynamically allocate the object.

So, based on what you told, I'd say it's best to have both possibilities: full initialization in the c'tor and a default c'tor with separate 'load' function.

[GCDEF]

The answer is it depends. In this case, for reasons already mentioned, I'd have the loading as a separate function.

[monarch_dodra]

It holds all the declination and stuff for my language.

Do you ever plan on having more than 1 dictionary? Would that even make sense? Sounds like what you have is a service, rather than an object you want to instantiate.

[Horsey]

The object is (and should be) a singleton. There is need for only one dictionary in program, loaded at beginning and being used till end of program work.
For user the dictionary is read-only. Any data operation (adding/removing, changing) should happen at program loading, not later.
When loading falls, dictionary is invalid and program exits.

Thanks for your answers, I think I'll leave this as it is right now.

[nuzzle]

The object is (and should be) a singleton. There is need for only one dictionary in program, loaded at beginning and being used till end of program work.
For user the dictionary is read-only. Any data operation (adding/removing, changing) should happen at program loading, not later.
When loading falls, dictionary is invalid and program exits.

Thanks for your answers, I think I'll leave this as it is right now.

The whole purpose of OO (and design patterns) is to make programs easy to change in the future. Your approach on the contrary seems to be - given the current situation how do I restrict my program maximally so that future change becomes as hard as possible. I'd say you're not following good programming style.

Instead anticipate that in the future your program may have to handle several dictionaries simultaneously, and that not all dictionary data are available at the time of object construction or that the total dictionaries may become so large that the whole of them cannot be stored in memory.

This has two immediate implications: Don't implement the dictionary object as a Singleton and don't "load it" in the constructor. It's bad design because it imposes unnecessary restrictions on future change.