У меня есть несколько объектов, которые вычисляли поля на них, такие как 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;
}
}
}
В порядке использования рассчитанных свойств, а не методов, если расчет не занимает заметного времени
Я думаю, что методы должны выполнять действия над объектом, как правило, изменять состояние объекта. Свойства должны отражать текущее состояние объекта, даже если вычисляется свойство. Поэтому вы должны сохранить свои свойства IMO.
Я думаю, что все они должны быть свойствами. Пока он не изменяет состояние объекта, я просто с этим согласен.
Кроме того, если я использую ваш класс для привязки данных (WPF и т.д.), я могу напрямую связать его с вашим свойством, не изменяя/расширяя класс.
Если они a) легкие и b) не имеют побочных эффектов, я бы сделал их Properties.
Легкий, конечно, немного нечеткий, но эмпирическое правило: если мне когда-либо придется беспокоиться о вызове свойства (будь то в цикле или в другом месте), это может быть метод.
Я оставил бы их как свойства. Но нет "стандартной" причины делать что-то так или иначе. Если вы сами, сделайте все, что вам больше нравится. Если вы находитесь в команде, следуйте правилам, которые придерживаются остальная часть вашей команды.
По-моему, это предпочтение; это то, что вы хотите сделать. В большинстве случаев я предпочитаю проприты, если только не задействована логика. Кроме того, если вам нужно передать параметры для изменения функциональности, то очевидно, что метод будет применяться...
Зависит, если ваши "свойства" становятся мамонтами и требуют целого множества бизнес-логики, они не должны быть свойствами, должен быть метод. Выбранный вами пример выглядит как свойство. Нет стандартного способа сделать это, пойдите своим инстинктом кишки; если это похоже на то, что вам нужно много сделать, вам, вероятно, нужен метод.
Если свойство особенно дорого рассчитать, я могу изменить его на метод GetWhatever(). Это служит подсказкой для тех, кто пользуется моим классом, что для этого значения требуется значительная работа, и вызывающий должен кэшировать значение, а не вызывать метод несколько раз.
Тривиальные вычисления отлично подходят внутри свойств.
В любом случае, это в значительной степени просто синтаксический сахар, поэтому вы хотите, чтобы вы были соглашением в своей команде или тем, что вы предпочитаете, до тех пор, пока оно просто возвращает информацию об объекте, а не меняет его или взаимодействует с другими объектами.
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
Теперь это не может быть свойство. Было бы намного лучше быть методом.
Иногда вам приходится учитывать также то, что вы моделируете... В некоторых доменах вычисленные значения часто или ожидаются как атрибут модели - свойство. Если это так, то напишите его как свойство, даже если вычисление вовсе не является тривиальным или немного дорогим для вычисления. Просто запишите его в свой API или создайте механизм кэширования, чтобы свести к минимуму перерасчет этого свойства.