2

I have a class, which I'll refer to as SpiderNest, that has a property of type List<Spider>, where Spider is a type of object with a property that is of type int; we'll call this property NumberOfLegs. I want either a method or property on the SpiderNest class to get the sum of the number of legs for all the spiders in my nest.

Would it be preferred to use a property like this (forgive poor object naming):

class SpiderNest {
    // Our example property.
    public List<Spider> Spiders { get; set; }

    public int TotalLegNumber 
    { 
        get { return Spiders.Sum(spider => spider.NumberOfLegs); } 
    }

Or a method?

class SpiderNest {
    public List<Spider> Spiders { get; set; }

    public int GetTotalNumberOfLegs() 
    {
        return Spiders.Sum(spider => spider.NumberOfLegs);
    }
}

And why would you choose that way? I know the question may be finicky but whenever I'm presented with two ways of doing something, there's usually benefits to each way of doing things. Thanks SO!

Wasif Hossain
  • 3,900
  • 1
  • 18
  • 20
Nick Bull
  • 9,518
  • 6
  • 36
  • 58

3 Answers3

5

The method has no side effects, however could be computationaly expensive if Spiders is large. If Spiders is large then it should be a method, otherwise make it a property.

Justin
  • 84,773
  • 49
  • 224
  • 367
  • 4
    To add a bit of clarification to Justin's answer: When you implement something as a property, you're hinting to your classes consumer that this is a relatively cheap and straightforward operation. This isn't set in stone, but when seeing a `NumberOfLegs` property or a `GetNumberOfLegs()` method, my instinct for the latter tells me it's an expensive operation whose results should be cached, while the former should be trivially repeatable. Be aware of those expectations. – Avner Shahar-Kashtan Mar 09 '14 at 08:30
  • That seems to be a very good rule of thumb. Thanks! – Nick Bull Mar 12 '14 at 19:17
1

Have a look at Choosing Between Properties and Methods on MSDN

Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects.

Do use a method, rather than a property [if] ...the operation is orders of magnitude slower than a field set would be [or] ...the operation has a significant and observable side effect.

Let's consider an example - if your List is populated from a database with lazy loading, so when you make a call to your list it is populated from the database - this means that when you ask for the total number of legs you could be waiting for the information to be populated - which is not an instant operation. In this case you would be better off using a method.

Additionally I always feel that saying GetXXX() implies that the method could return a different value at different points in execution whereas a property feels like it should be more of a static number. On this basis I would err towards GetXXX() if you plan to be adding spiders to your nest after initiation.

dav_i
  • 27,509
  • 17
  • 104
  • 136
0

Another hint would be if it would produce side effects (like changing another property or some internal state). If yes, make it a method even if it is cheap.

In your specific case i would make it a property. If the calculation could take long (due to the fact the list constains int.MaxValue items) i would create within the property itself a cache that will calculate this value once when it will be called the first time or when the list has been changed since the last calculation of it. Or maybe calculate beforehand every time the sum when the list changes and within your property you simply return the latest calculated value. But all these possibilities are depending on the design of the list elements (e.g. are they immutable or implementing INotifyPropertyChanged?) and how often the list changes vs. how often will the sum be needed by a client.

Oliver
  • 43,366
  • 8
  • 94
  • 151