Re: [Boost-users] Library Interface Design

From: Anne-Gert Bultena (list-aap_at_[hidden])
Date: 2006-09-12 08:50:15

I hope I summarized your pros and cons correctly here:

1) 'complete' constructors show the user what to do to use the class.

2) 'incomplete' constructors are easier to use, because they incur less (so-called) overhead.

> I've slept soundly with this philosophy for many years, but lately I've
> noticed that this idea runs headlong into one of the ideas of
> testability:  that classes should be easy to test in isolation.  The
> above constructor requires that an ostream be set up before an EventLog
> can be tested, and this might (1) be a pain and (2) be irrelevant for
> whatever test I want to perform.  In such cases, offering a default
> constructor in addition to the above would make the class potentially
> easier to test.  (In the general case, there might be many parameters,
> and they might themselves be hard to instantiate for a test due to
> required parameters that their constructors require....)

3) Because of 2 and because (many) of the arguments are 'irrelevant', 'incomplete' constructors
are easier in testing, because you get your test-object faster.

4) 'incomplete' constructors are easier when exploring classes.

5) .NET Framework designers know what they're doing.

My oppinion is that 'complete' constructors are better then 'incomplete'. I read that most of you
feel the same.
I also am a big fan of having sufficient overloads to instantiate a class from different
perspectives (ie with different arguments). Usually a constructor with many default arguments
works very convenient for me.
A constructor should only set what is required to get the desired behaviour. Therefore, there *is*
no overhead: all arguments are NECESSARY if not, additional constructor overloads can be created.
This makes items 2 and 3 IMHO less important. The use of interfaces may greately ease the
construction of test-stubs. In C++, I of course mean multiple inheritance with abstract
'interface' base-classes.
As for Item 1, I believe that it's very important to tell the user of a class what is expected of
the user and what the class provides. One can do this in comments (XML comments in .NET are great
for that, I think), but if given the choice I prefer 'self-documenting' compilable code, like
argument names and types.
I'm not going to comment on item 5 :-)

In short, I think the advantages of 'complete' constructors outweigh the disadvantages and the
disadvantages can be reduced by proper design and interfaces.

my 2 cents,

agb