Когда использовать свойства вместо функций
Это не ответ, но действительно больше мысль и возможно другой вопрос. Мне это звучит, как будто это может быть реализовано через своего рода рычаг или триггер.
Некоторая программа в фоновом режиме могла бы наблюдать папку только для записи (не путем опроса, она может быть уведомлена с FAM или что-то как этот), и затем переместите каждый файл из нее в папку только для чтения, как только это появляется.
6 ответов
Я предпочитаю использовать свойства, если выполняются следующие условия:
- Свойство возвращает единственное логическое значение
- Логика практически отсутствует (обычно просто возвращается значение или выполните небольшую проверку / возврат значения)
Я предпочитаю использовать методы, если выполняются следующие условия:
- Для возврата значения потребуется значительная работа, то есть: оно будет получено из БД или что-то, что может занять «время»
- При получении или установке значения требуется довольно много логики.
Кроме того, я бы рекомендовал ознакомиться с Руководством Microsoft по проектированию для использования свойств . Они предлагают:
Используйте свойство, когда элемент является логическим элементом данных.
Используйте метод, когда:
- Операция является преобразованием, например Object.ToString.
- Операция достаточно дорогостоящая, поэтому вы хотите сообщить пользователю, что ему следует рассмотреть вопрос о кэшировании результата.
- Получение значения свойства с помощью метода доступа get будет иметь заметный побочный эффект.
- Вызов члена дважды в последовательность дает разные результаты.
- Порядок выполнения важен. Обратите внимание, что свойства типа должны иметь возможность устанавливаться и извлекаться в любом порядке.
- Член является статическим, но возвращает значение, которое можно изменить.
- Член возвращает массив. Свойства, возвращающие массивы, могут вводить в заблуждение. Обычно необходимо вернуть копию внутреннего массива, чтобы пользователь не мог изменить внутреннее состояние. Это в сочетании с тем фактом, что пользователь может легко предположить, что это индексированное свойство, приводит к неэффективному коду. В следующем примере кода каждый вызов свойства Methods создает копию массива. В результате в следующем цикле будет создано 2n + 1 копий массива.
Вот рекомендации Microsoft:
Выбор между свойствами и методами
Рассмотрите возможность использования свойства, если член представляет логический атрибут типа.
Используйте свойство, а не метод, если значение свойства хранится в памяти процесса, и свойство просто предоставляет доступ к значению.
Используйте метод, а не свойство, в следующих ситуациях.
Операция выполняется на несколько порядков медленнее, чем при установке поля. Если вы даже рассматриваете возможность предоставления асинхронной версии операции, чтобы избежать блокировки потока, весьма вероятно, что операция слишком дорога, чтобы быть свойством. В частности, операции, которые обращаются к сети или файловой системе (кроме одного раза для инициализации), скорее всего, должны быть методами, а не свойствами.
Операция представляет собой преобразование, такое как метод Object.ToString.
Операция возвращает другое результат каждый раз, когда он вызывается, даже если параметры не меняются. Например, метод NewGuid при каждом вызове возвращает другое значение.
Операция имеет значительный и заметный побочный эффект. Обратите внимание, что заполнение внутреннего кэша обычно не считается наблюдаемым побочным эффектом.
Операция возвращает копию внутреннего состояния (это не включает копии объектов типа значения, возвращаемых в стеке).
Операция возвращает array.
Я использую свойства, когда его семантика ясна: «Получить какое-то значение от объекта». Однако использование метода - хороший способ сообщить, что «для возврата может потребоваться немного больше, чем тривиальное усилие».
Например, коллекция может иметь свойство Count . Разумно предположить, что объект коллекции знает, сколько элементов в настоящее время хранится, без необходимости перебирать их и подсчитывать их.
С другой стороны, эта гипотетическая коллекция может иметь метод GetSum (), который возвращает общую сумму набора элементов Ручной. Вместо этого у коллекции просто есть свойство Sum, но с помощью метода она передает идею о том, что коллекции придется проделать некоторую реальную работу, чтобы получить ответ.
Я бы никогда не использовал свойство, если бы мог влиять более чем на одно поле - I ' публичная строка ErrorLog {получить; частный набор; } синтаксис для свойств и методов использования для всего остального.
В дополнение к ответу Рида, когда свойство будет только получателем, таким как получение ресурса, например журнала событий. Я стараюсь использовать свойства только тогда, когда они не имеют побочных эффектов.
Если в свойстве происходит нечто большее, чем что-то тривиальное, то это должен быть метод. Например, если ваше свойство-получатель ErrorLog действительно работает и читает файлы, то это должен быть метод. Доступ к свойству должен быть быстрым, и если он выполняет большую обработку, это должен быть метод. Если есть побочные эффекты доступа к свойству, которых пользователь класса может не ожидать, то, вероятно, это должен быть метод.
Существует книга .NET Framework Design Guidelines , в которой описываются подобные вещи. очень подробно.