C# read-only calculated properties, should they be

问题:

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;
        }
    }
}

回答1:

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

回答2:

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.

回答3:

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.

回答4:

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.

回答5:

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.

回答6:

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...

回答7:

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.

回答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.

回答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.

回答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.

回答11:

Sometimes, you have to consider also what you're modeling... On some domains, the calculated values are often or expected to be an attribute of the model -- a Property. If this were the case, then write it as a Property even though the calculation is not at all trivial or a little bit expensive to compute. Just document it on your API or implement some caching mechanism to minimize recomputation for this property.