Когда использовать свойства вместо функций
Это, вероятно, вопрос личных предпочтений, но когда вы используете свойства вместо функций в вашем коде
Например, чтобы получить журнал ошибок, я мог бы сказать
string GetErrorLog()
{
return m_ErrorLog;
}
или я мог
string ErrorLog
{
get { return m_ErrorLog; }
}
Как вы решаете, какой из них использовать? Кажется, я не согласен в своем использовании, и я ищу хорошее общее правило. Спасибо.
Ответы
Ответ 1
Я предпочитаю использовать свойства, если верно следующее:
- Свойство вернет одно логическое значение
- Мало или вообще не задействована логика (обычно просто возвращают значение или делают небольшое значение check/return)
Я стараюсь использовать методы, если верно следующее:
- Будет проведена значительная работа по возврату значения - то есть: он будет извлечен из БД или что-то, что может занять время.
- Существует довольно немного логики, связанной с получением или настройкой значения
Кроме того, я бы рекомендовал посмотреть Руководства по дизайну Microsoft для использования в свойствах. Они предлагают:
Использовать свойство, когда элемент является логическим элементом данных.
Использовать метод, когда:
- Операция - это преобразование, например Object.ToString.
- Операция достаточно дорогая, что вы хотите сообщить пользователю, что они должны учитывать кеширование результата.
- Получение значения свойства с помощью get accessor будет иметь наблюдаемый побочный эффект.
- Вызов члена дважды подряд дает разные результаты.
- Порядок выполнения важен. Обратите внимание, что свойства типа должны быть установлены и извлечены в любом порядке.
- Элемент статический, но возвращает значение, которое можно изменить.
- Элемент возвращает массив. Свойства, возвращающие массивы, могут вводить в заблуждение. Обычно необходимо возвращать копию внутреннего массива, чтобы пользователь не мог изменить внутреннее состояние. Это, в сочетании с тем, что пользователь может легко предположить, что это индексированное свойство, приводит к неэффективному коду. В следующем примере кода каждый вызов свойства Методы создает копию массива. В результате в следующем цикле будет создано 2n + 1 копия массива.
Ответ 2
Вот рекомендации Microsoft:
Выбор между свойствами и методами
-
Рассмотрим использование свойства, если элемент представляет собой логический атрибут типа.
-
Использовать свойство, а не метод, если значение свойства хранится в памяти процесса, и свойство просто предоставит доступ к значению.
-
Использовать метод, а не свойство, в следующих ситуациях.
-
Операция на порядок медленнее, чем набор полей. Если вы даже планируете предоставить асинхронную версию операции, чтобы избежать блокировки потока, очень вероятно, что операция слишком дорого, чтобы стать свойством. В частности, операции, которые обращаются к сети или файловой системе (за исключением инициализации), скорее всего, будут методами, а не свойствами.
-
Операция представляет собой преобразование, например метод Object.ToString.
-
Операция возвращает другой результат при каждом вызове, даже если параметры не изменяются. Например, метод NewGuid возвращает различное значение при каждом вызове.
-
Операция имеет значительный и наблюдаемый побочный эффект. Обратите внимание, что заполнение внутреннего кеша обычно не рассматривается как наблюдаемый побочный эффект.
-
Операция возвращает копию внутреннего состояния (это не включает копии объектов типа значения, возвращаемых в стек).
-
Операция возвращает массив.
Ответ 3
Я использую свойства, когда он очищает семантику: "Получить некоторое значение от объекта". Однако использование метода - это хороший способ общения, "это может занять немного больше, чем тривиальное усилие для возврата".
Например, коллекция может иметь свойство Count
. Разумно предположить, что объект коллекции знает, сколько элементов в данный момент хранится без фактического прохождения через них и подсчета их.
В руке эта гипотетическая коллекция может иметь метод GetSum(), который возвращает общее количество сохраненных элементов. В коллекции просто есть свойство Sum, но, используя метод, он передает идею о том, что коллекция должна будет выполнить некоторую реальную работу, чтобы получить ответ.
Ответ 4
Я бы никогда не использовал свойство, если бы я мог влиять на несколько полей - я всегда использовал метод.
Как правило, я просто использую
public string ErrorLog {get; частный набор; }
синтаксис свойств и использование методов для всего остального.
Ответ 5
В дополнение к Reed ответ, когда свойство будет собираться только как getter, например, получить такой ресурс, как журнал событий. Я пытаюсь использовать свойства только тогда, когда свойство будет свободным от побочных эффектов.
Ответ 6
Если в свойстве есть нечто большее, чем тривиальное, то это должен быть метод. Например, если ваше свойство ErrorLog getter действительно собиралось и читало файлы, тогда это должен быть метод. Доступ к объекту должен быть быстрым, и если он выполняет большую обработку, это должен быть метод. Если есть побочные эффекты доступа к свойству, которого не может ожидать пользователь класса, тогда он должен, вероятно, быть методом.
Существует . Руководство по дизайну .NET Framework, в котором подробно описывается этот материал.