Re: [Boost-users] Library Interface Design

From: Geoff Worboys (geoff_at_[hidden])
Date: 2006-09-14 23:13:17

It seems to me that what constitutes an initialised state of an
object is largely library defined.  One size does not fit all,
some libraries will suit certain tasks better than others.  As
long as the state after construction is known and documented
then it seems that even the EventLog with a default constructor
would be a strictly correct (if not that useful) design.

Some of the main reasons for two phase construction is to allow
for relationships between long lived objects, and often to
allow complex operational properties to be assigned or adjusted
dynamically through the life of the objects - without
constraint from external (outside program control) objects.

Whether it is called "two phase construction" or whether it is
just that we say the object is defined as having an active and
inactive state does not matter much.  AFAICT this is the
principle that is being discussed.

Mostly I am thinking of database and GUI applications, but we
can demonstrate the principle using a file class (ignoring
the availability of streams)...

  MyFileClass f;  // an empty, unopen, unnamed file object
  f.set_file_name("afile"); // a named but still unopen file
  f.open(ForRead);  // now an open for reading the file

Is it bad to allow MyFileClass to be constructed in this way?

It would seem to partially violate the resource acquisition
is initialisation principle although exactly what happens
internally I have not defined and it can still ensure
appropriate release of resources when the object is destroyed.

The advantage of such a system is the ability to hook up
potentially complex objects and use events (or signals or
whatever you want to call them) to keep them in touch using
observer patterns.

For example we may connect an object to f and observe signals
that it sends out about what file it represents, whether it is
open, and perhaps the contents of the file.  ie. Your typical
document/view sort of thing.

Someone earlier mentioned vehicles (amongst other things)
as an example of an object we expect to arrive in a fully
constructed state.  And this is a good example of what I am
talking about here.

I DO expect my car to be fully constructed when I get it - but
I DONT expect it to be continually in motion, or have the
engine running all the time.  If I press the accelerator when
it is not running then nothing happens.  It is a fully
constructed object, it is just not very useful until it has
been turned on.  (cf. MyFileClass when not open.  A car does
not have to be turned on to exist, a file does not have to be
open to exist - it is just that some things are not possible
until the object is active.)

I may want to engage four wheel drive.  I dont mind turning it
off while I do it (if I have too), but I dont expect to take
the entire car to pieces and reassemble it in four wheel drive
mode.  (cv. MyFileClass when open for read and want to write.)

I have many applications where the same principles apply.  The
objects have complex relationships and may have many defining
or dynamically adjustable attributes.  It is not always
convenient to destroy and recreate entire sets of objects
every time I want to change some aspect of their operation.

That is my current take on it.  Single phase construction is
obviously best where feasible - it keeps everything simpler and
clearer.  But at this time I can see no alternative but two
phase construction (objects with active/inactive state) for
some situations.

Are there practical alternatives?
If so I'd love to hear about them.

-- 
Geoff Worboys
Telesis Computing