local paramater versus several "gets"

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,
I am new to object oriented programming and .net. I have a question
concerning using singletons.

Lets say I have the following:

public class Engine
{
public static readonly Engine Instance = new Engine();//singleton
private Device device;

public Device Device
{
get{return device;}
}

//other stuff omitted
}

public class OtherClass
{
public void Method1()
{
Engine.Instance.Device.Method1
Engine.Instance.Device.Method2
Engine.Instance.Device.Method3
Engine.Instance.Device.Method4
}

}

Calling OtherClass.Method1 implemented this way, requires a device "get" 4
different times.

Would it be faster and/or better programming to create a local device
variable at the start of Method1 and set this equal Engine.Instance.Device?
public void Method1()
{
Device device = Engine.Instance.Device;
device.Method1
device.Method2
device.Method3
device.Method4
}
Any experienced advice would be greater appreciated.

Thanks,
Dan
 
Of course it would... for the reason you gave, the alternative is for the
get function to be invoked many times. It also increases readability and
maintainability.
 
Here's a description of when it's better to use a property over a method.
It comes from FxCop and I've found it helpfull in the past:

In most cases, properties represent data, while methods perform actions.
Properties are accessed like fields, which makes them easier to use. If a
method takes no arguments and returns an object's state information, or
accepts a single argument to set some part of an object's state, it is a
good candidate for becoming a property.

Properties should behave as though they are fields; if the method cannot, it
should not be changed to a property. Methods are preferable to properties in
the following situations:

a.. The method performs a time-consuming operation. The method is
perceivably slower than the time it takes to set or get a field's value.
b.. The method performs a conversion. (Accessing a field does not return a
converted version of the data it stores.)
c.. The "Get" method has an observable side effect. (Retrieving a field's
value does not produce any side effects.)
d.. The order of execution is important. (Setting the value of a field
does not rely on other operations having occurred.)
e.. Calling the method twice in succession creates different results.
f.. The method is static but returns an object that can be changed by the
caller. (Retrieving a field's value does not allow the caller to change the
data stored by the field.)
g.. The method returns an array.
 
John,
Thanks for your reply. Out of curiousity, does anyone know if the compiler
will optimize the first version?

Thanks,
Dan
 
Thx,
That helps alot!
Dan
Rhy Mednick said:
Here's a description of when it's better to use a property over a method.
It comes from FxCop and I've found it helpfull in the past:

In most cases, properties represent data, while methods perform actions.
Properties are accessed like fields, which makes them easier to use. If a
method takes no arguments and returns an object's state information, or
accepts a single argument to set some part of an object's state, it is a
good candidate for becoming a property.

Properties should behave as though they are fields; if the method cannot, it
should not be changed to a property. Methods are preferable to properties in
the following situations:

a.. The method performs a time-consuming operation. The method is
perceivably slower than the time it takes to set or get a field's value.
b.. The method performs a conversion. (Accessing a field does not return a
converted version of the data it stores.)
c.. The "Get" method has an observable side effect. (Retrieving a field's
value does not produce any side effects.)
d.. The order of execution is important. (Setting the value of a field
does not rely on other operations having occurred.)
e.. Calling the method twice in succession creates different results.
f.. The method is static but returns an object that can be changed by the
caller. (Retrieving a field's value does not allow the caller to change the
data stored by the field.)
g.. The method returns an array.
Click to expand...
 
Hi John,

I'm not quite sure whether it will be optimized, because it is very
specific to compiler implementation.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Back
Top