CODEWITHSUNDEEP
c#.netc#-4.0
deen
deen

Reputation: 487

When should I prefer property over method?

When should I prefer property over method ? Because the following code is more readable when I use property.

string agency = base.GetAgencyDetails();

string agency = base.Agency; //I could write same logic in getter of the property.

Upvotes: 3

Views: 348

Answers (5)

JaredPar
JaredPar

Reputation: 754585

At their core properties are meant to be a wrapper over field access and provide unification between normal and calculated fields. Any operation which is akin to a field access should be represented as a property when possible.

That's not an absolute rule, it's a guideline. It's hard to draw up definitive rules for what should be a property over a method. However the reverse is not true; it is very clear when a method should be preferred over a property.

  • The operation has a visible side effect on the type. For example if it visibly mutates any state in the object the operation should never be a property.
  • Long running operations including expensive operations should never be properties

Upvotes: 0

Brandon Moretz
Brandon Moretz

Reputation: 7621

A property is simply a set of wrapper method (get/set) around a backing field.

The prefered way is to use a property so your external contract doesn't change, however you could later add additional logic or validations to the property methods.

Also makes the code cleaner as a bonus.

Upvotes: 0

SP007
SP007

Reputation: 1921

Ref from enter link description here

In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.

Upvotes: 0

Rudi Visser
Rudi Visser

Reputation: 21969

Personally, I'd follow the MSDN Guidelines on this.

In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.

It makes perfect sense if you think about it, a method would be more suited to something that would potentially alter data in some way, and a property is perfect for when you're retrieving some data and caching it.

If you're using an explicitly backed property, you could even combine the two in the case of a transform:

private ObjType _myObjWithStringification;
private string _stringRepOfData;

public string StringRepresentation
{
    get {
        if (_stringRepOfData == null) {
            _stringRepOfData = _myObjWithStringification.ToString();
        }
        return _stringRepOfData;
    }
}

Re: Your maintainability comment, I'm not sure it's very much valid. If you were to hit F12 to go to the declaration of the property you're using, you'll go straight to the getter anyway, just like you'd go to the method body if you used a method.

I'm not sure it's safe to assume that a property isn't going to have any custom retrieval logic.

Upvotes: 11

Cristian Chereches
Cristian Chereches

Reputation: 505

If you have to write a lot of logic, then method, not property.

If you do a method call in the logic, then again method, not property.

Upvotes: 2

Related Questions