tags:

views:

146

answers:

5

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?

+3  A: 

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

jcollum
Yep, exactly the same thing under the covers
Chris Ballance
+1  A: 

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
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
+1  A: 

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  A: 

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
A: 

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