Thank you all for answering.
I'm afraid relying on setters does not solve the problem of omitting
the init of one of the params. Using default values and validation
might help, but not when using types like bool, in which true and
false are valid, and there could be no default value. Also, this
approach does the validation at run time. If possible, I'd like check
to be done at compile time.
After reading your suggestions and giving it some more thought, I had
a new idea, which combines all 3 options: Given that object copying is
not a problem (and it's really not, in this case), I could use a
parameters' class. That class will have several init functions,
divided by some sensible criteria, each initializing a different
subset of parameters. Making sure a few needed inits were called is
easier than making sure many setters were called, and the compiler
will make sure each call to any of the inits has been done with all
the right arguments. How does that sound?
Eran
I'm afraid relying on setters does not solve the problem of omitting
the init of one of the params. Using default values and validation
might help, but not when using types like bool, in which true and
false are valid, and there could be no default value. Also, this
approach does the validation at run time. If possible, I'd like check
to be done at compile time.
After reading your suggestions and giving it some more thought, I had
a new idea, which combines all 3 options: Given that object copying is
not a problem (and it's really not, in this case), I could use a
parameters' class. That class will have several init functions,
divided by some sensible criteria, each initializing a different
subset of parameters. Making sure a few needed inits were called is
easier than making sure many setters were called, and the compiler
will make sure each call to any of the inits has been done with all
the right arguments. How does that sound?
Eran