To use a read-only property or a method?

Question

I need to expose the "is mapped?" state of an instance of a class. The outcome is determined by a basic check. It is not simply exposing the value of a field. I am unsure as to whether I should use a read-only property or a method.

Read-only property:

public bool IsMapped
{
    get
    {
        return MappedField != null;
    }
}

Method:

public bool IsMapped()
{
    return MappedField != null;
}

I have read MSDN's Choosing Between Properties and Methods but I am still unsure.

Solution 1

The C# standard says

§ 8.7.4

A property is a member that provides access to a characteristic of an object or a class. Examples of properties include the length of a string, the size of a font, the caption of a window, the name of a customer, and so on. Properties are a natural extension of fields. Both are named members with associated types, and the syntax for accessing fields and properties is the same. However, unlike fields, properties do not denote storage locations. Instead, properties have accessors that specify the statements to be executed when their values are read or written.

while as methods are defined as

§ 8.7.3

A method is a member that implements a computation or action that can be performed by an object or class. Methods have a (possibly empty) list of formal parameters, a return value (unless the method’s return-type is void ), and are either static or non-static.

Properties and methods are used to realize encapsulation. Properties encapsulate data, methods encapsulate logic. And this is why you should prefer a read-only property if you are exposing data. In your case there is no logic that modifies the internal state of your object. You want to provide access to a characteristic of an object.

Whether an instance of your object IsMapped or not is a characteristic of your object. It contains a check, but that's why you have properties to access it. Properties can be defined using logic, but they should not expose logic. Just like the example mentioned in the first quote: Imagine the String.Length property. Depending on the implementation, it may be that this property loops through the string and counts the characters. It also does perform an operation, but "from the outside" it just give's an statement over the internal state/characteristics of the object.

Solution 2

I would use the property, because there is no real "doing" (action), no side effects and it's not too complex.

Solution 3

I personally believe that a method should do something or perform some action. You are not performing anything inside IsMapped so it should be a property

Solution 4

I'd go for a property. Mostly because the first senctence on the referenced MSDN-article:

In general, methods represent actions and properties represent data.

Solution 5

In this case it seems pretty clear to me that it should be a property. It's a simple check, no logic, no side effects, no performance impact. It doesn't get much simpler than that check.

Edit:

Please note that if there was any of the above mentioned and you would put it into a method, that method should include a strong verb, not an auxiliary verb like is or has. A method does something. You could name it VerifyMapping or DetermineMappingExistance or something else as long as it starts with a verb.

View more solutions

Comments

[Dave New]

But in the same light, then why is IEnumerable.Count() a method?

[Lotok]

It does a count...(an action)

[Dave New]

But I am also doing an action... a null check

[Lotok]

You are checking a piece of data, not performing an action on it. - If based on the result you did something else or performed a calc or something, then it would be a method.

[Dave New]

But MappedField != null is by definition a logic statement.

[Mr47]

With this definition, what about an indexed property?

[Zoran Horvat]

IEnumerable.Count() is an extension method which basically walks through the collection and counts contains elements. On the other hand, IList.Count is a property because it doesn't traverse the list - list already knows its count and simply returns it from the property.

[Dave Van den Eynde]

IEnumerable.Count() doesn't exist. Count() is an extension method, found in the static class Enumerable, and 1) extension properties don't exist and 2) Count() is likely to be time consuming (especially in complex LINQ queries).

[Dave New]

In this example you are performing multiple null checks. How is this logically different from mine, where I am also performing a null check?

[Dave New]

"You want to provide access to a characteristic of an object." - this is what I was looking for. This is the most complete answer with the appropriate MSDN references. Thanks.

[user]

You assume here that reading MappedField is simple, fast and has no side effects. We don't know that to be true.

[Odys]

If that value has major part in the object, then yes we might.

[Nakilon]

I wish coders say such "I don't use *** because there are no arguments, why do I neeed it" as frequently as possible.

[Sayse]

Its different as you do not know the answer until you have queryed every member of mf

[nvoigt]

@MichaelKjörling Obviously, he could have implemented a custom operator != that formats his hard disk, but you can break all things in many ways. As long as nothing is specified, I will assume that what I see is standard compliant.

[Andrew Hanlon]

While not a hard and fast rule, I would tend to also use a method when the computation time to return a property is non trivial. Properties should return immediately.

[Vlad]

+1 for clear focusing on semantics and not on formal criteria

[Carsten]

@sysexpand: IEnumerable.Count() is an extension method, that's right, but the only reason why it is an extension method is, because there are not extension properties. IList.Count could traverse the whole list, depending on the interface implementation. It is impossible for an interface to define it's implementation - however it is possible to decide whether or not an field of an object is an characteristic (data/property) or an operation (method).