С# только для чтения рассчитанные свойства, должны ли они быть методами?

У меня есть несколько объектов, которые вычисляли поля на них, такие как TotalCost. Сейчас у меня есть все как свойства, но мне интересно, должны ли они на самом деле быть методами. Есть ли для этого стандарт С#?

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

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

Ответы

Ответ 2

Я думаю, что методы должны выполнять действия над объектом, как правило, изменять состояние объекта. Свойства должны отражать текущее состояние объекта, даже если вычисляется свойство. Поэтому вы должны сохранить свои свойства IMO.

Ответ 3

Я думаю, что все они должны быть свойствами. Пока он не изменяет состояние объекта, я просто с этим согласен.

Кроме того, если я использую ваш класс для привязки данных (WPF и т.д.), я могу напрямую связать его с вашим свойством, не изменяя/расширяя класс.

Ответ 4

Если они a) легкие и b) не имеют побочных эффектов, я бы сделал их Properties.

Легкий, конечно, немного нечеткий, но эмпирическое правило: если мне когда-либо придется беспокоиться о вызове свойства (будь то в цикле или в другом месте), это может быть метод.

Ответ 5

Я оставил бы их как свойства. Но нет "стандартной" причины делать что-то так или иначе. Если вы сами, сделайте все, что вам больше нравится. Если вы находитесь в команде, следуйте правилам, которые придерживаются остальная часть вашей команды.

Ответ 6

По-моему, это предпочтение; это то, что вы хотите сделать. В большинстве случаев я предпочитаю проприты, если только не задействована логика. Кроме того, если вам нужно передать параметры для изменения функциональности, то очевидно, что метод будет применяться...

Ответ 7

Зависит, если ваши "свойства" становятся мамонтами и требуют целого множества бизнес-логики, они не должны быть свойствами, должен быть метод. Выбранный вами пример выглядит как свойство. Нет стандартного способа сделать это, пойдите своим инстинктом кишки; если это похоже на то, что вам нужно много сделать, вам, вероятно, нужен метод.

Ответ 8

Если свойство особенно дорого рассчитать, я могу изменить его на метод GetWhatever(). Это служит подсказкой для тех, кто пользуется моим классом, что для этого значения требуется значительная работа, и вызывающий должен кэшировать значение, а не вызывать метод несколько раз.

Тривиальные вычисления отлично подходят внутри свойств.

Ответ 9

В любом случае, это в значительной степени просто синтаксический сахар, поэтому вы хотите, чтобы вы были соглашением в своей команде или тем, что вы предпочитаете, до тех пор, пока оно просто возвращает информацию об объекте, а не меняет его или взаимодействует с другими объектами.

Ответ 10

MSDN предоставляет информацию об этом здесь

Дизайнеры библиотеки классов часто должны решить между внедрением класса член как свойство или метод. В общие, методы представляют собой действия и свойства представляют данные.

Какой из них вы считаете? Действие вычисляет /getLaborCost или данные?

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

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

но если вы собираетесь сделать это для одного и того же объекта:

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

Теперь это не может быть свойство. Было бы намного лучше быть методом.

Ответ 11

Иногда вам приходится учитывать также то, что вы моделируете... В некоторых доменах вычисленные значения часто или ожидаются как атрибут модели - свойство. Если это так, то напишите его как свойство, даже если вычисление вовсе не является тривиальным или немного дорогим для вычисления. Просто запишите его в свой API или создайте механизм кэширования, чтобы свести к минимуму перерасчет этого свойства.