Constructors should be simple, predictable, and never fail.
Keep your constructors simple in the sense that:
- Few parameters. Ever hear that a “function should do one thing and do it
well”? It applies to constructors, too.
- Few overrides. Don’t try to get around the previous dictum by having a bunch
of overrides on the constructors. It’s confusing for someone to understand
the initial state if there are a bunch of initial states.
- Leave the work to public methods. If you think everything the constructor
needs to be able to provide the ultimate configuration for an object you are
trying to control (constrict) some developers too much.
We write code like:
int days = 13;
and don’t expect initialization to be doing very much work. Developers are used to that. Same with:
MyType val = new MyType(arg1, arg2);
should just be doing initialization comparable to assigning that integer. If
you want to have the constructor do a bunch of database work, factor that out
into a separate method:
Many times people with constructor fever think have an underlying mindset that
thinks an object should be completely initialized and everything handled at the
constructor level. If you make every member function “const” then I’d believe
you. Otherwise, it’s just being a control freak.
A constructor shouldn’t fail except under the most exceptional of circumstances
(out of memory). Examples of things that are not exceptional: a file doesn’t
exist, a network connection doesn’t succeed, input is poorly formatted, etc.