Software Design Thoughts

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.

Never fail

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.