General Question about Object Creation

[Charles Law]

As a matter of practice, where would people put the following elements of
object creation/initialisation:

Create shared member objects
Initialise shared member objects
Create non-shared member objects
Initialise non-shared member objects
Initialise peripherals

The places where these could take place would appear to be

Constructor
Initialise method (or Load method)
.... any where else?

Is there any convention for naming an initialise method?

The scenario I have in mind is where an object communicates with some
external equipment. This object needs to load its configuration from some
xml files before it can do anything sensible, but I am not sure whether the
constructor is the right place to do this. The object does not always have
to communicate with the external equipment (it might not be attached, for
example). In this case, I do not want to insist that the user connect the
equipment and power it on just so that they can use some features of this
object. It's a bit like the WebBrowser control and mshtml (loosely). The
user can load the browser and render html, or just use the mshtml bit for
parsing and stuff.

In my case, the object can be used to control the external equipment, or
used to provide general configuration information about the equipment.

Any and all thoughts welcome.

TIA

Charles

 

[Guest]

This is what makes sense to me:

 

[Charles Law]

Hi Amiram

Thanks for the reply.

The xml files (three of them) are used to initialise shared objects, so
would you include them in the shared constructor?

The reason for my hesitation is that I usually try to avoid performing
operations in the constructor that could fail, and if one or more of the
files is missing then the constructor would fail.

Charles

 

[Guest]

If you put code that initialize shared objects in a nonshared constructor,
the shared objects will be initialized each time you create an object, and
you probably don't want that to happen.
If you worried about a failure in the constructor, and the code that might
fail is not critical to the main program, put a try catch block.

 

[Charles Law]

It would actually be fatal if the shared constructor code failed, so I guess
I let the exception happen. The only other reason that I have put it into a
method in the past is that it takes time to execute; something else that I
try to avoid in constructors, but perhaps not a good enough reason.

Charles

 

[Tom Shelton]

It would actually be fatal if the shared constructor code failed, so I guess
I let the exception happen. The only other reason that I have put it into a
method in the past is that it takes time to execute; something else that I
try to avoid in constructors, but perhaps not a good enough reason.

Charles

Charles - the only thing to be warry of is that if you let an exception
be thrown form the shared constructor then the client code is going to
actually receive a TypeInitializationException. They can get at the
actual exception by looking at the InnerException property, but it is
something that you might want to document if this code is meant to be
used by developers other then your self.

 

[Charles Law]

Hi Tom

Thanks for the pointer. I have actually gone away from the shared
constructor idea, because I need to give my class a parameter to tell it
where to find the config files, and shared constructors can't take
parameters; unless there is another way?

I have put the file load into a standard constructor, but it does mean that
a client has to create an instance of my class in order to use shared
properties. I am not sure how to get round this.

Charles