Design issue: Property vs. Method

  • Thread starter Thread starter Jeff Robichaud
  • Start date Start date
J

Jeff Robichaud

Hello,

I have an obect that needs to inform the outside world wheter prices are
synchronized or not. My first idea was to use a public property for this:

public bool PricesSynchronized

But I need to access a database and the query takes a (relatively) long time
to run. So for any code that will use this property, I just find it strange
that it's going to take time, because usually a public property is used to
simply publish some internal data, sometimes performing simple calculations,
sometimes just preveting write acces to internal data (using get without
set).

I have never seen a property that takes time to process so I would tend to
use a method here instead. But on the other hand, methods are usually used
to perform tasks on the object, whereas properties are used to get some info
about the object...I know this is somehow philosophical but what would be
the best choice here (from a design point of view) ??....
 
I think to recall that MS recommendation (and common sense) is to use
methods for actions that can take some time to be executed. Properties are
expected to be executed very fast.

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
 
I would have a method called ".SyncPrices()" on the object, and then a
property that returns the specific data. That way, you are seperating the
calculation of the information from its use.

In general, it is poor practice to put code into a property that will take
substantial time to execute or could raise errors that the caller would be
surprised to see. In other words, how strange would it be to get a SQL
error on the following line?

bool ArePricesSynced = myObject.PricesSynchronized;


--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
Back
Top