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]

Do you have any specific information that makes you think that you can't or
shouldn't do this sort of thing in a property?

In my view, a property can be considered to be a'kin to an adjective (a
describing word) and a method can be considered to be a'kin to a verb (an
action word).

Taking, as an example, an animal class, it might have a boolean property
'EatsGrass' and a method 'EatGrass'. The former 'describes' whether or not
the animal does eat grass while the latter instructs the animal to carry out
the 'action' eat grass.

Sometimes the distinction between whether to implement something as a
property or a method can be subtle and sometimes it can simply be a matter
of choice.

In your case, it is clear that you have a collection (Things) of Thing
objects. While each Thing object has a Duration property, the Things
collection has a Duration property being the sum of the Duration properties
of it's members.

In this case the use of a property is valid because Duration describes
something about the collection of Thing objects.
"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?

[Brian Gideon]

In this particular example I would chose a function over a property.
The reason is because a lot (most?) people assume that properties are
constant time operations. They may repeated call the property without
realizing the performance effect it may have.

If you still think it makes since to make it a property then at least
document that runtime is linear and not constant.

Also, I believe the Framework Design Guidelines book in the Microsoft
..NET Development Series recommends keeping the runtime of properties
constant.

Brian

sklett wrote:

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]

"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

[Lucian Wischik]

"sklett" <sk****@mddirec t.com> wrote:

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?"

In your example, my instinct would be to memo-ize it -- i.e. keep a
private nullable field which is the lazy result of the computation,
and when you call the "get" method it computes the answer if necessary
and stores it in that nullable field as a side-effect (so can be
retrieved later), and also have a central "Invalidate " field which
re-zeroes all such nullable fields upon any possibly-change-causing
set.

What this has done, of course, is turn a one-line piece of code into a
sixty-line object...

--
Lucian

[Stephany Young]

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

[Lucian Wischik]

Lucian Wischik <lu***@wischik. com> wrote:

retrieved later), and also have a central "Invalidate " field which
re-zeroes all such nullable fields upon any possibly-change-causing

I meant, "a central protected Invalidate method" which is called by
all your relevant setter methods.

--
Lucian

[Bruce Wood]

> In this particular example I would chose a function over a property.

The reason is because a lot (most?) people assume that properties are
constant time operations.

I don't know about "constant time operations," but it's true that
properties shouldn't take much time to execute. That said, I have many,
many properties in the framework I built at my company that could, in
theory, go back to the database for information, so they're waaaay over
"constant time."

You see, it's not always so cut-and-dried.

On the one hand, if you make something a property, you are implying
that getting the information will be quick. So, if getting the
information is slow, that is a hint that it shouldn't be a property.

On the other hand, you don't want to determine what is a property or
not based upon implementation details. By doing so you're letting the
internal guts of how your class works leak out into its interface with
the outside world. That's bad style. So, something should be a property
if it makes sense that it be a property.

Certainly, anything that affects the state of the object in a manner
more sophisticated than just "set this to that" should be a method.
That's painfully obvious.

Similarly, an aspect of your class that can be read and set, even if
setting it does more than just set a variable, should probably be a
property. Reasonably straightfoward.

However, sometimes the two design goals above-properties that return
results quickly and not letting implementation determine
interface-are at odds with each other, and you have to make a
judgement call.

In the case of my system, I had things that logically should be
properties (from an interface point of view) but the object held only
keys, not references to the objects themselves, so the "get" on the
property has to fetch the object in question from the database. It was
an open question whether to code:

Supplier theSupplier = stockItem.Suppl ier;

or

Supplier theSupplier = stockItem.GetSu pplier();

I chose the former, preferring to hide the implementation (holding
supplier UID, not supplier itself) rather than let it leak out that
getting the supplier was actually a lot of work. In our case it's no
problem, because we're a very small shop. In a different situation I
might have gone for door #2.

In your case, I would definitely make it a property. The fact that you
have to loop through some stuff is an implementation detail and, as
Lucian pointed out, you could always cache the result to avoid
recalculating it the second and subsequent times. You might even be
able to keep the "answer" up to date internally as your object is
modified.

That's why the design guideline about not choosing property / method
based on implementation is there: because next month you may think of a
different implementation that is much faster, but you've already made
it a method when it would have made more sense as a property.

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

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.

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++]) there may be necessary
actions to take when getting/setting a property. This, I would consider, to
be valid behavior in an accessor function.

Here's another keyword from C++ that I'm not sure exists in C# (need to read
up some, I can see :): "mutable" - meaning a data member that can be changed
even if the object is otherwise required to be const. A mutable data member
might be a reference counter, for example - that is related to the
management of the object, not its value. Accessor methods can probably be
safely expected to touch mutable data members in order for their operation
to be complete.

HTH,
Chris
"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?