C# read-only calculated properties, should they be methods?

Question

I have several entities that have calculated fields on them such as TotalCost. Right now I have them all as properties but I'm wondering if they should actually be methods. Is there a C# standard for this?

public class WorkOrder
{
    public int LaborHours { get; set; }
    public decimal LaborRate { get; set; }

    // Should this be LaborCost()?
    public decimal LaborCost
    {
        get
        {
            return LaborHours * LaborRate;
        }
    }
}

Answer 1

In my opinion, it's a preference; it's what you want to do. I do propreties in most cases, unless there is logic involved. Additionally, if you need to pass in parameters to change the functionality then obviously a method would apply...

Answer 2

It's OK to use calculated properties rather than methods, as long as the calculation doesn't take a noticeable time

See Property usage guidelines

Answer 3

I would leave them as properties. But there's not "standard" reason to do things one way or another. If you're by yourself, do whatever you like best. If you're on a team, then follow conventions the rest of your team are following.

Answer 4

I think methods should perform actions on the object, typically change the state of the object. Properties should reflect the current state of the object even if the property is calculated. So you should keep your properties IMO.

Answer 5

Depends, if your "properties" become mammoths and require a whole slew of business logic they shouldn't be properties, there should be a method. The example you posted looks ok to be a property. No standard way of doing it, go with your gut instinct; if it looks like it needs to do a lot you probably need a method.

Answer 6

If they are a) lightweight and b) have no side effects, I would make them Properties.

Lightweight is a bit fuzzy of course, but the rule of thumb is: If I ever have to worry calling a Property (be it in a loop or anywhere else), it should possibly be a method.

Answer 7

I think they should all be properties. As long as it doesn't change the state of the object, I'm cool with it as a property.

Additionally, if I'm using your class for data binding (WPF, etc.), then I can bind directly to your property without having to modify/extend the class.

Answer 8

If a property is particularly expensive to calculate, I might change it to a GetWhatever() method. This serves as a hint to whoever uses my class that this value requires some significant work to arrive at, and the caller should cache the value rather than calling the method multiple times.

Trivial calculations are perfectly appropriate inside of properties.

Answer 9

It's largely just syntactic sugar anyway, so do want you is convention in your team, or what you prefer, as long as it is just returning information about the object and not changing it or interacting with other objects.

Answer 10

MSDN gives information about this here

Class library designers often must decide between implementing a class member as a property or a method. In general, methods represent actions and properties represent data.

Which one do you think it is? An action calculate/getLaborCost or data?

WorkOrder workOrder = new WorkOrder();
workOrder.LaborHours = 8;
workOrder.LaborRate = 20;

decimal cost = workOrder.LaborCost; // This is OK here

but if you are going to do this for the same object also:

worOrder.LaborHours = 18;
decimal newCost = workOrder.LaborCost 

Now this cannot be a property. It would be a lot better to be a method.