2

I have a class that has some properties. And I want something that calculates a Score out of these properties. Since this is a trivial task (some additions and divisions, but nothing spectacular).

So naturally, the question is: "When to use a Property with some code in the getter, and when to use a function?", and that question was already answered.

Now, I wonder about one thing though: If - against all expectations - I ever needed to make this Getter so complicated that it should be a function (for example, because I need to put data in or because it can throw an exception or whatever), is it easy to change a Property into a Method?

Of course, it seems really trivial, just changing

public double Score {
    get {
        return Math.Round(A + B / C * D,3);
    }
}

to

public double Score(){
    return Math.Round(A + B / C * D,3);
}

But I wonder: Are there any side effects? Is anything going to break when changing stuff around like this? I can only ever see this as a possible problem when Reflection is involved, but what in situations where I have 2 Assemblies - one that defines the class and one that uses the class - and only change the one that contains the class without recompiling the consumer assembly. Is that a possible source of "weird bugs that are nearly impossible to track" or is it completely safe to change Properties to Methods?

Community
  • 1
  • 1
Michael Stum
  • 177,530
  • 117
  • 400
  • 535

5 Answers5

3

Pull up reflector, you'll see that your properties already are methods :)

jcollum
  • 43,623
  • 55
  • 191
  • 321
1

No. There are no side affects to this at all.

Pull up reflector, you'll see that your properties already are methods

Under the hood the get and set accessors in a property are simply converted to get_MyPropertyName() and set_MyPropertyName() methods. This is also why you can (but typically shouldn't) add parameters to a property.

The only "gotcha" is that in C# you will need to add "()" to any existing calls.

Also

according to the coding guidelines, a property name usually is noun (i.e. Score), but methods should describe actions (verb), so more proper name is GetScore() or CalculateScore()

Micah
  • 111,873
  • 86
  • 233
  • 325
  • Thanks. I was just afraid that there is some more hidden black magic. Accepting this answer because it is more elaborate, but upvoted both. – Michael Stum Nov 17 '08 at 20:30
1

If you are going to change from property to method and allow the compiler to show you where to add the parethesis, you could get subtle bugs as object ting = thing.score ting would be a boxed double for the property version of score but a delegate for a method version of score therefore different code path would result where:

public void erm(double param){ //stuff here}
public void erm(func<double> param) {// different stuff here}

when you call with

erm(thing.score)

with the property versus method version of score.

PhilHoy
  • 1,613
  • 1
  • 12
  • 20
1

One side affects is breaking all the calling code to this property. You will have update all callers to us the method signature rather then property

Aaron Fischer
  • 20,853
  • 18
  • 75
  • 116
0

As others already pointed out - nothing to worry. I just post to clarify that according to the coding guidelines, a property name usually is noun (i.e. Score), but methods should describe actions (verb), so more proper name is GetScore() or CalculateScore() :)

Grammar Nazi in action :)

Sunny Milenov
  • 21,990
  • 6
  • 80
  • 106