When an object is required to provide some simple true/false information about itself one may use a method or a property to return a boolean value.

The question is which is preferable to use? Or does it even matter. I'm sure there are solid design reasons for going either way.

An example of what I am talking about is:
bool-returning method - IsBlah() vs. a [possibly readonly] property - IsBlah.

Each will provide its return value depending on the internal state of the object. The syntax will differ, as well as the accessibility (properties can have mutators). What else is different?

One major difference is that in C# a property with both get and set accessors can be inadvertently assigned to via a small typo:

if (obj.State = serverState)...
when you mean,
if (obj.State == serverState)

Obviously this can be avoided by only providing a get accessor, however this can't always be done because some properties need mutators too. Another fix would be to enforce a coding style where the comparison value always appears on the LHS of the comparison - not stable though, as it depends on the developer.

Bill Wagner at SRT Solutions suggests that there are no hard-and-fast rules, but that some simple guidelines may be followed in order to make the decision. This checklist can be found here. Some good points he makes in favour of properties is that they can be serialised, which is definitely becoming more and more important as web services gain popularity. In the context of .NET this also affects objects sent over a Remoting boundary.

Personaly, I prefer to use properties whenever possible as they fit well with the concept that they are exposing an attribute of the object. I definitely agree with Bill in that they should be simple, settable in any order, and should not call outside the object to determine their value. I think it is wise to use private methods to calculate properties based on external data, and then cache that result for when it is required via the property. This can be done when the object is created.

As always, it depends on the particular requirements for the object. If the attribute in question can be safely calculated from internal state at any time in the object's lifetime, then a property is the way to go. If the attribute can only be calculated after the constructor has finished, or if the attribute depends on external data, a calculation method and caching solution, or a re-design/refactoring would be preferable.

To illustrate:

A caveat I have encountered when using properties which calculate data upon access is that they may negatively affect scalability. When the class is designed, the designer may have envisioned only a few of the objects being used at a time. However, if a list of hundreds of these objects is created and then bound to a control, the get property will be called hundreds of times, calculating the return value each time. This will lead to poor response-time as the number of items increases. So if you're sure the object's property will only be used a few time in a given system operation it is ok to calculate on the fly. Otherwise it is essential to pre-populate the data, cache the data used in the calculation in a static member, or redesign/refactor the class. An elegant solution to this problem is to use the Assembler pattern in combination with DTO's, which I will discuss soon in another post.