Property or Function?

[sklett]

I just found myself doing something I haven't before:
<code>
public uint Duration
{
get
{
uint duration = 0;
foreach(Thing t in m_things)
{
duration += t.Duration;
}

return duration;
}
}
</code>

And it made me think... "Is that OK to do stuff" in a property?" and "How do
you decide to use a property or a function?"

So, that's my question: Are there guidelines for deciding what goes into a
property and what should be a function?

[Stephany Young]

Tha's a spurious argument because now it's ice, it's not Drink any more -
rather it is Not Drink.

<s> wrote in message news:cd******** ************@co mcast.com...

Drink.IsLiquid - has much value: my beer is warm; I stick it in the
freezer to cool down quickly and forget; now Drink.IsLiquid returns false.

Chris
Beware of dragons: to them you are a crunchy snack and taste good with
ketchup
"Stephany Young" <noone@localhos t> wrote in message
news:ue******** ******@TK2MSFTN GP05.phx.gbl...

How so?

A readonly property is natural e.g. Drink.IsLiquid - A drink, by
definition is liquid so what point would there be in the IsLiquid
property of Drink being updateable?

Also, by there very nature, properties are self-documenting, i.e., a
property with a get accessor but no set accessor is readonly, a property
with a set accessor but no get accessor is writeonly and a property with
both accessors is read/write.

It is not a matter of 'information hiding'. It is a matter of providing
the appropriate functionality to solve the problem at hand.
"David" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:LQDZf.301$ iF3.190@dukerea d01...

"sklett" <sk****@mddirec t.com> wrote in message
news:OL******** *****@TK2MSFTNG P05.phx.gbl...
I just found myself doing something I haven't before:
<code>
public uint Duration
{
get
{
uint duration = 0;
foreach(Thing t in m_things)
{
duration += t.Duration;
}

return duration;
}
}
</code>

And it made me think... "Is that OK to do stuff" in a property?" and
"How do you decide to use a property or a function?"

So, that's my question: Are there guidelines for deciding what goes
into a property and what should be a function?

I don't know about any guidlines but "informatio n hiding" can be a
double edged sword. In my view "get" without "set" works very well with
reference types but confuses things when used to return values.

David

[Jon Skeet [C# MVP]]

<<s>> wrote:

Drink.IsLiquid - has much value: my beer is warm; I stick it in the freezer
to cool down quickly and forget; now Drink.IsLiquid returns false.

That's fine - but Stephany asked the point of it being *updateable*. I
would suggest that in this case you wouldn't tell the drink that it was
no longer liquid, but perhaps tell it its temperature and let it decide
when it becomes solid.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

<<s>> wrote:

I would go back to OO first principles: what is the 'isness' of the object?
If you suspect your property is doing "too much" that could be a clue that
your object is fuzzy around the edges (not sure if it's one thing or
another).

A second principle I would apply (I just thought of it as I was perusing the
posts, so have never actually tested it in a real situation) is this:
setting or getting any property should not alter the value of any other
property. Calling a method can be expected to alter the values of any or all
of the object's properties - and naturally the method's behavior can be
expected to vary depending on the properties' values at the time it was
called.
I'm not sure I agree with that. It makes sense that if you set one
property, it shouldn't change another *writable* property, but I don't
think it's a problem to affect a readonly property. For instance, a
rectangle might have orthogonal settable Width and Height properties,
but setting those properties could affect the readonly Area property. I
don't think that's a problem, and in many cases it is positively
beneficial.
Depending on your application's threadiness, or interaction with physical
devices (otherwise known as 'volatile' addresses [hmm - not sure if the
'volatile' keyword made its way into C# from C/C++])

It did, but with somewhat different semantics.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Carl-Johan Wik]

As one can see in this thread there is many ways to look at this.

In my teaching I present this problem area as

Property: Hold data
Methods: Manipulate(/process) data

Now the question come as you have, what about computed properties. Well as
someone state here, properties should be fast in execution. As a user of
your class expect the property to have a "value" and should be able to
retrieve this value in a "fast" manner. So the question is how can you
return this value fast.

Compute it on access of pre-compute it.

In your case you have compute on access and this might be ok for this case.

You could have changed it and computed this value every time a "thing" is
added to the "things". Making it pre-computed, and get a fast access of the
property.

What way to choice, well I would say it is different from case to case. (
and programmer :-) )

/cjw
"sklett" <sk****@mddirec t.com> wrote in message
news:OL******** *****@TK2MSFTNG P05.phx.gbl...

I just found myself doing something I haven't before:
<code>
public uint Duration
{
get
{
uint duration = 0;
foreach(Thing t in m_things)
{
duration += t.Duration;
}

return duration;
}
}
</code>

And it made me think... "Is that OK to do stuff" in a property?" and "How
do you decide to use a property or a function?"

So, that's my question: Are there guidelines for deciding what goes into
a property and what should be a function?

[David]

"Stephany Young" <noone@localhos t> wrote in message
news:ue******** ******@TK2MSFTN GP05.phx.gbl...

How so?
In the example given the duration was calculated. Calculate is a verb.
Calculating duration within a get accessor hides the fact that it needs to
be calculated without providing the benifit of simplifying the code. It's
information misleading rather than information hiding.

A readonly property is natural e.g. Drink.IsLiquid - A drink, by
definition is liquid so what point would there be in the IsLiquid property
of Drink being updateable?

Also, by there very nature, properties are self-documenting, i.e., a
property with a get accessor but no set accessor is readonly, a property
with a set accessor but no get accessor is writeonly and a property with
both accessors is read/write.

It is not a matter of 'information hiding'. It is a matter of providing
the appropriate functionality to solve the problem at hand.
"David" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:LQDZf.301$ iF3.190@dukerea d01...

"sklett" <sk****@mddirec t.com> wrote in message
news:OL******** *****@TK2MSFTNG P05.phx.gbl...

I just found myself doing something I haven't before:
<code>
public uint Duration
{
get
{
uint duration = 0;
foreach(Thing t in m_things)
{
duration += t.Duration;
}

return duration;
}
}
</code>

And it made me think... "Is that OK to do stuff" in a property?" and
"How do you decide to use a property or a function?"

So, that's my question: Are there guidelines for deciding what goes
into a property and what should be a function?

I don't know about any guidlines but "informatio n hiding" can be a double
edged sword. In my view "get" without "set" works very well with
reference types but confuses things when used to return values.

David

[Stephany Young]

Who cares if the Duration was calculated or not. All the consumer needs to
know that when the property is 'queried' it returns the value. The consumer
has absolutely no need to know how the functionality is implemented.

That is the beauty of the whole concept.

Next you'll have use back to directly manipulating registers!
"David" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:2yNZf.312$ iF3.64@dukeread 01...

"Stephany Young" <noone@localhos t> wrote in message
news:ue******** ******@TK2MSFTN GP05.phx.gbl...

How so?

In the example given the duration was calculated. Calculate is a verb.
Calculating duration within a get accessor hides the fact that it needs to
be calculated without providing the benifit of simplifying the code. It's
information misleading rather than information hiding.

A readonly property is natural e.g. Drink.IsLiquid - A drink, by
definition is liquid so what point would there be in the IsLiquid
property of Drink being updateable?

Also, by there very nature, properties are self-documenting, i.e., a
property with a get accessor but no set accessor is readonly, a property
with a set accessor but no get accessor is writeonly and a property with
both accessors is read/write.

It is not a matter of 'information hiding'. It is a matter of providing
the appropriate functionality to solve the problem at hand.
"David" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:LQDZf.301$ iF3.190@dukerea d01...

"sklett" <sk****@mddirec t.com> wrote in message
news:OL******** *****@TK2MSFTNG P05.phx.gbl...
I just found myself doing something I haven't before:
<code>
public uint Duration
{
get
{
uint duration = 0;
foreach(Thing t in m_things)
{
duration += t.Duration;
}

return duration;
}
}
</code>

And it made me think... "Is that OK to do stuff" in a property?" and
"How do you decide to use a property or a function?"

So, that's my question: Are there guidelines for deciding what goes
into a property and what should be a function?

I don't know about any guidlines but "informatio n hiding" can be a
double edged sword. In my view "get" without "set" works very well with
reference types but confuses things when used to return values.

David

[Jon Skeet [C# MVP]]

David <Co*********@Ad sorptionProcess Modeling.com> wrote:

How so?

In the example given the duration was calculated. Calculate is a verb.
Calculating duration within a get accessor hides the fact that it needs to
be calculated without providing the benifit of simplifying the code. It's
information misleading rather than information hiding.

It's only misleading if you regard properties as being restricted to
just returning values without doing any calculations at all.

What counts as a calculation, anyway? If an indexer needs to access
another collection in order to return a value, does that count as a
calculation? What about multiplying two fields (eg width and height) to
return an area?

While I agree that a member being a property implies there won't be
*very* much calculation involved, I wouldn't want to restrict myself to
only things which required no calculations. Examples of things from the
framework which wouldn't be properties in that case:

String.Length
FileStream.Leng th
FileStream.Name
FileStream.Posi tion
Pretty much all the DateTime properties
Most of the Type properties
Most of the Environment properties
etc

Would you rather they weren't properties?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Nick Hounsome]

"sklett" <sk****@mddirec t.com> wrote in message
news:OL******** *****@TK2MSFTNG P05.phx.gbl...

I just found myself doing something I haven't before:
<code>
public uint Duration
{
get
{
uint duration = 0;
foreach(Thing t in m_things)
{
duration += t.Duration;
}

return duration;
}
}
</code>

And it made me think... "Is that OK to do stuff" in a property?" and "How
do you decide to use a property or a function?"

So, that's my question: Are there guidelines for deciding what goes into
a property and what should be a function?

It's not OK regardless of the time complexity or semantics of the class.
It's not OK because it is uint and uint is not CLS compliant.

Regarding the other arguments:
Don't use a property if it is going to take significant time to calculate.
That is what people expect and it is wrong to say that it shouldn't matter -
nobodyuses a property or method thinking "well this might take 10ms or 3
hours but who cares". Theoretically you could document its time behaviour
but we all know that that is not going to work well in practice. Having a
user cache the value of a property just seems wrong and as for whoever it
was who said that their class might go to the database to get a property
value I just wouldn't want to work with their software.

If number of Thing can be large then I'd go for the keeping track of it
rather than calculating afresh each time or providing a method.

[Bruce Wood]

Nick,

Fortunately for both of us you don't have to work with my software, nor
I with yours. :-)

I don't recommend writing a property that has to head off to the
database. It was an experimental thing which hasn't caused us any
problems here because the few of us working here understand what's
involved. It's become a "local idiom," if you will. The first access is
slow; all subsequent accesses are lightning fast.

However, in retrospect, I would probably have made these methods, even
though it (unfortunately) leaks information about the implementation
into the interface. Certainly I would make them methods if our software
were ever to be used outside our tiny shop.

We're going to rewrite the whole thing soon anyway... the first effort
was a throwaway.

Anyway, that was an extreme example. The point was (and still stands)
that it's sometimes not a simple thing to decide between method and
property. O-O principles tell us "don't expose implementation details
in your public interface," while sensible .NET convention tells us
"properties should execute quickly." Sometimes those two goals are at
odds and you have to weigh each one off against the other.

"A property can never do any calculations" is silly, just as "a
property can do anything it likes" is silly. The truth is somewhere in
between.

[Kevin Spencer]

I think that the controversy has chiefly stemmed from the fact that the
emphasis here has been misplaced. The emphasis of this thread has been on
what a property should or should not *do.* In fact, I believe the
controversy can be avoided altogether (by reasonable minds) by shifting the
emphasis to what a property *is*. This is OOP, and OOP is all about
abstraction. A property is called a "property" because it represents a
"property of an object." Now, we all know that an object is not really an
object, but an abstraction of an encapsulation of process and data that are
treated as part of the same "thing" in order to make it easier for us
humans, who more naturally think abstractly about almost everything, to work
with that process and data. We all know what the word "property" has meant
since long before it was used in programming terms: " A characteristic trait
or peculiarity, especially one serving to define or describe its possessor."
Like the words "class," "type," and "object," the word "property" was
employed to describe the abstraction that the programming definition of
"property" represents.

In the same vein, the word "method" is defined in the English language as "A
means or manner of procedure, especially a regular and systematic way of
accomplishing something." Therefore, the appellations of these 2 terms
should tend to indicate when each rule should be employed. The confusion
arises because in programming, a property has a get and/or set "method" to
return the "value" of the property. However, is this not true in real life
as well? For example, a human being has a "property" called "weight." How is
the weight known? It is not stored as a number somewhere in the person. It
is obtained by a "method" which employs using a measuring device of some
kind to weigh the person.

Of course, in the realm of programming, as in real life, it is not optimal
to calculate any property every time the state is required. Some properties
are stored, and calculated less often, to save processor work. The same can
be said of real-life properties. Does a person step on a scale every time
their weight is requested of them? No, they weigh themselves occasionally,
and report the results, which are accurate enough for general purposes, but
may not be exact, when asked. If an accurate measurement is required, the
person can step onto the scales again, executing the "method" by which the
"property" is obtained.

In other words, a "property" in programming is appropriate for use in
obtaining what can be abstractly termed as "a characteristic or trait" of an
object, while a "method" is appropriate for use when describing a "means or
manner of procedure." That is, regardless of what sort of calculation may be
involved, it is the abstraction which is important. Creating a property for
any method that takes no arguments would be silly. Creating a method for any
process that is required to obtain data is equally silly. The only "correct"
definition is that for which the terms were originally employed - as
abstractions in an abstract paradigm.

I hope this serves to put out those flames.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ g10g2000cwb.goo glegroups.com.. .

Nick,

Fortunately for both of us you don't have to work with my software, nor
I with yours. :-)

I don't recommend writing a property that has to head off to the
database. It was an experimental thing which hasn't caused us any
problems here because the few of us working here understand what's
involved. It's become a "local idiom," if you will. The first access is
slow; all subsequent accesses are lightning fast.

However, in retrospect, I would probably have made these methods, even
though it (unfortunately) leaks information about the implementation
into the interface. Certainly I would make them methods if our software
were ever to be used outside our tiny shop.

We're going to rewrite the whole thing soon anyway... the first effort
was a throwaway.

Anyway, that was an extreme example. The point was (and still stands)
that it's sometimes not a simple thing to decide between method and
property. O-O principles tell us "don't expose implementation details
in your public interface," while sensible .NET convention tells us
"properties should execute quickly." Sometimes those two goals are at
odds and you have to weigh each one off against the other.

"A property can never do any calculations" is silly, just as "a
property can do anything it likes" is silly. The truth is somewhere in
between.