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

[Amiram Korach]

This is what makes sense to me:
"Charles Law" wrote:

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

Create shared member objects Shared constructor Initialise shared member objects Shared constructor Create non-shared member objects constructor Initialise non-shared member objects constructor Initialise peripherals Load
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

[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
"Amiram Korach" <Am**********@discussions.microsoft.com> wrote in message
news:91**********************************@microsof t.com...

This is what makes sense to me:
"Charles Law" wrote:

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

Create shared member objects

Shared constructor

Initialise shared member objects

Shared constructor

Create non-shared member objects

constructor

Initialise non-shared member objects

constructor

Initialise peripherals

Load

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

[Amiram Korach]

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" wrote:

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
"Amiram Korach" <Am**********@discussions.microsoft.com> wrote in message
news:91**********************************@microsof t.com...

This is what makes sense to me:
"Charles Law" wrote:

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

Create shared member objects

Shared constructor

Initialise shared member objects

Shared constructor

Create non-shared member objects

constructor

Initialise non-shared member objects

constructor

Initialise peripherals

Load

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

[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
"Amiram Korach" <Am**********@discussions.microsoft.com> wrote in message
news:E6**********************************@microsof t.com...

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" wrote:

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
"Amiram Korach" <Am**********@discussions.microsoft.com> wrote in message
news:91**********************************@microsof t.com...

> This is what makes sense to me:
> "Charles Law" wrote:
>
>> As a matter of practice, where would people put the following elements
>> of
>> object creation/initialisation:
>>
>> Create shared member objects
> Shared constructor
>> Initialise shared member objects
> Shared constructor
>> Create non-shared member objects
> constructor
>> Initialise non-shared member objects
> constructor
>> Initialise peripherals
> Load
>>
>> 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
>>
>>
>>

[Tom Shelton]

In article <u2**************@TK2MSFTNGP10.phx.gbl>, Charles Law wrote:

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.

--
Tom Shelton [MVP]
OS Name: Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 2 Build 2600
System Up Time: 7 Days, 14 Hours, 56 Minutes, 22 Seconds

[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
"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:Ob**************@tk2msftngp13.phx.gbl...

In article <u2**************@TK2MSFTNGP10.phx.gbl>, Charles Law wrote:

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.

--
Tom Shelton [MVP]
OS Name: Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 2 Build 2600
System Up Time: 7 Days, 14 Hours, 56 Minutes, 22 Seconds