Properties

[Mike J]

I have a Queston about Properties vs Public / protected

ive read alot where people say dont use public or protected members always
use Properties....

i kinda dis-agree with that.
I do want to here from others

i may have a class where i dont care about isolation
so why not make a public field

there are time where i need isolation and then i use Properties
What kind of Preformance hit to incur in a loop with properties.....
versus public/private fields and Properties

Tks
MJ

 

[Bruce Wood]

I have a Queston about Properties vs Public / protected

ive read alot where people say dont use public or protected members always
use Properties....

i kinda dis-agree with that.
I do want to here from others

i may have a class where i dont care about isolation
so why not make a public field

there are time where i need isolation and then i use Properties
What kind of Preformance hit to incur in a loop with properties.....
versus public/private fields and Properties

There is no performance hit. The JITter will in-line simple properties
into direct field accesses. So, in the end all we're talking about is
lines of code, not performance.

If you search this group for "properties vs fields" you'll find dozens
of threads on that topic. This discussion comes up frequently.

 

[Nicholas Paldino [.NET/C# MVP]]

Mike,

If you know for sure that the class is never going to be changed, and
that there will never be an addition of logic when a value is set/retrieved,
then fields would be fine.

In the end, it's up to you, but you have to realize what the penalty for
a wrong decision is. If you have to change a field to a property, then
anything compiled against the assembly with the old type will have to be
recompiled. That could be a little work or a lot, depending on the
visiblity of the type, and how widely distributed it is.

As for performance, a field access is always going to be faster than
accessing a property (which just sets a value or returns a value) because a
property is really a method call underneath the covers. In a tight loop
with a large number of iterations, you could probably measure a performance
difference.

 

[Nicholas Paldino [.NET/C# MVP]]

I should note that if you have a property that is that simple, and it is
not virtual, then it is most likely a candidate for inlining, and that could
give you performance on the level of field accesses.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Mike,

If you know for sure that the class is never going to be changed, and
that there will never be an addition of logic when a value is
set/retrieved, then fields would be fine.

In the end, it's up to you, but you have to realize what the penalty
for a wrong decision is. If you have to change a field to a property,
then anything compiled against the assembly with the old type will have to
be recompiled. That could be a little work or a lot, depending on the
visiblity of the type, and how widely distributed it is.

As for performance, a field access is always going to be faster than
accessing a property (which just sets a value or returns a value) because
a property is really a method call underneath the covers. In a tight loop
with a large number of iterations, you could probably measure a
performance difference.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I have a Queston about Properties vs Public / protected

ive read alot where people say dont use public or protected members
always use Properties....

i kinda dis-agree with that.
I do want to here from others

i may have a class where i dont care about isolation
so why not make a public field

there are time where i need isolation and then i use Properties
What kind of Preformance hit to incur in a loop with properties.....
versus public/private fields and Properties

Tks
MJ

 

[Marc Gravell]

People have mentioned performance (JIT), and you aren't fussed on the
encapsulation - but another view: functionality. If you want to use
your object for binding (e.g. MVP) then note that the default
reflective view does not make fields available. That said, I have seen
a TypeDescriptionProvider that exposes fields as PropertyDescriptor
instances, so you can get around this...

Marc

 

[Mike J]

just Did a Test with 30000 rows (70 columns)
disconnected Record set
Reading a column , Console to the screen
with a MyClass wrote and the primitive record set
in this test
property on my test was 1 second faster than public fields
example :below
so properties i would say rule of thumb (unless thought about more)

int itmp
while (!MyTable.Eof) //Property
{


itmp = (int)MyTable.ColumnGet("MyTable1500_ID");
Console.Writ(MyTable.RowPos.ToString()); // Property
Console.WriteLine(itmp.ToString());


MyTable.Skip();
}

// the below was slower by 1 second than the top loop

mytable.GoTop()
while (!MyTable.Eof) //Changed To public Field
{


itmp = (int)MyTable.ColumnGet("MyTable1500_ID");
Console.Writ(MyTable.RowPos.ToString()); // Changed to
public Field
Console.WriteLine(itmp.ToString());


MyTable.Skip();
}

I should note that if you have a property that is that simple, and it
is not virtual, then it is most likely a candidate for inlining, and that
could give you performance on the level of field accesses.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Mike,

If you know for sure that the class is never going to be changed, and
that there will never be an addition of logic when a value is
set/retrieved, then fields would be fine.

In the end, it's up to you, but you have to realize what the penalty
for a wrong decision is. If you have to change a field to a property,
then anything compiled against the assembly with the old type will have
to be recompiled. That could be a little work or a lot, depending on the
visiblity of the type, and how widely distributed it is.

As for performance, a field access is always going to be faster than
accessing a property (which just sets a value or returns a value) because
a property is really a method call underneath the covers. In a tight
loop with a large number of iterations, you could probably measure a
performance difference.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I have a Queston about Properties vs Public / protected

ive read alot where people say dont use public or protected members
always use Properties....

i kinda dis-agree with that.
I do want to here from others

i may have a class where i dont care about isolation
so why not make a public field

there are time where i need isolation and then i use Properties
What kind of Preformance hit to incur in a loop with properties.....
versus public/private fields and Properties

Tks
MJ

 

[Mike J]

thanks for the Response
MJ

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I have a Queston about Properties vs Public / protected

ive read alot where people say dont use public or protected members always
use Properties....

i kinda dis-agree with that.
I do want to here from others

i may have a class where i dont care about isolation
so why not make a public field

there are time where i need isolation and then i use Properties
What kind of Preformance hit to incur in a loop with properties.....
versus public/private fields and Properties

Two general rules:
1) if the class will never be used more than once, then you can
use public properties
2) if the class will never be used more than once, then rewrite
it so that it can



Arne