Почему я должен избегать использования Свойств в C#?

Ну, позволяет, берут его аргументы один за другим:

Свойство может быть только для чтения или только для записи; доступ к полю всегда читаем и перезаписываем.

Это - победа для свойств, так как Вы имеете более мелкомодульный контроль над доступом.

Метод свойства может выдать исключение; доступ к полю никогда не выдает исключение.

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

• Свойство не может быть передано как или касательно параметра к методу; поле может.

Ясно.

• Метод свойства может занять много времени для выполнения; доступ к полю всегда сразу завершается.

Может также потребоваться очень мало времени.

• Если названо многократно подряд, метод свойства может возвратить другое значение каждый раз; поле возвращает то же значение каждый раз.

Не верно. Как Вы знаете, что значение поля не изменилось (возможно другим потоком)?

Система. Класс DateTime имеет свойство Now только для чтения, которое возвращает текущую дату и время. Каждый раз, когда Вы запрашиваете это свойство, оно возвратит различное значение. Это - ошибка, и Microsoft жаль, что они не могли зафиксировать класс путем создания Теперь метода вместо свойства.

Если это - ошибка, это - незначительное.

• Метод свойства может вызвать заметные побочные эффекты; доступ к полю никогда не делает. Другими словами, пользователь типа должен смочь установить различные свойства, определенные типом в любом порядке, который он выбирает без того, чтобы замечать любое другое поведение в типе.

Ясно.

• Метод свойства может потребовать дополнительной памяти или возвратить ссылку на что-то, что не является на самом деле частью состояния объекта, так изменение возвращенного объекта не имеет никакого эффекта на исходный объект; запросы поля всегда возвращают ссылку на объект, который, как гарантируют, будет частью состояния исходного объекта. Работа со свойством, которое возвращает копию, может очень сбивать с толку разработчиков, и эта характеристика часто не документируется.

Большинство заявлений могло быть сказано для методов считывания и методов set Java также - и у нас были они долгое время без таких проблем на практике.

Я думаю, что большинство проблем могло быть решено лучшей подсветкой синтаксиса (т.е. дифференцирующиеся свойства от полей), таким образом, программист знает, что ожидать.

Я не вижу оснований, почему Вы не должны использовать Свойства в целом.

Автоматические свойства в C# 3 + только упрощают синтаксис немного (а-ля синтетический сахар).

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

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

Если я ввожу Foo.Bar, люди, читающие его, будут обычно ожидать, что это просто получает доступ к членскому полю класса Foo. Это - дешевая, почти бесплатная, операция, и это детерминировано. Я могу назвать его много раз и получить тот же результат каждый раз.

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

Это - подобный аргумент тому, почему Linus ненавидит C++. Ваш код может действовать, удивляя читателю. Он ненавидит перегрузку оператора: a + b не обязательно означает простое дополнение. Это может означать некоторую чрезвычайно сложную операцию, точно так же, как свойства C#. Это может иметь побочные эффекты. Это может сделать что-либо.

Честно, я думаю, что это - слабый аргумент. Оба языка полны вещей как это. (Мы должны избежать оператора, перегружающегося в C# также? В конце концов, тот же аргумент может использоваться там),

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

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

Однако у меня есть другая причина найти их менее, чем прекрасными. Они не могут быть переданы в отношении других функций.

Поля могут быть переданы как ref, разрешение вызванной функции получить доступ к нему непосредственно. Функции могут быть переданы как делегаты, позволив вызванной функции получить доступ к нему непосредственно.

Свойства... не могут.

Это сосет.

Но это не означает, что свойства являются злыми или не должны использоваться. Во многих целях они являются великими.

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

Это - всего мнение одного человека. Я прочитал довольно много книг c#, и я должен все же видеть, что кто-либо еще говорить "не использует свойства".

Я лично думаю, что свойства являются одной из лучших вещей о c#. Они позволяют Вам выставлять состояние с помощью любого механизма, который Вы любите. Можно лениво инстанцировать в первый раз, когда что-то используется, и можно сделать проверку при устанавливании значения и т.д. При использовании и записи им, я просто думаю о свойствах как о методах set и методах считывания который намного более хороший синтаксис.

Что касается протестов со свойствами, существует пара. Каждый - вероятно, неправильное употребление свойств, другой может быть тонким.

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

Например.

public class WorkerUsingMethod
{
   // Explicitly obvious that calculation is being done here
   public int CalculateResult()
   { 
      return ExpensiveLongRunningCalculation();
   }
}

public class WorkerUsingProperty
{
   // Not at all obvious.  Looks like it may just be returning a cached result.
   public int Result
   {
       get { return ExpensiveLongRunningCalculation(); }
   }
}

Я нахожу, что использование методов для этих случаев помогает сделать различие.

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

Скажите, что у Вас есть некоторое свойство как это:

public int Result 
{ 
   get 
   { 
       m_numberQueries++; 
       return m_result; 
   } 
}

Теперь предположите, что у Вас есть исключение, которое происходит, когда слишком много запросов сделаны. Угадайте то, что происходит, когда Вы начинаете отлаживать и трансформация свойство в отладчике? Плохие вещи. Постарайтесь не делать это! Рассмотрение свойства изменяет состояние программы.

Это единственные протесты, которые я имею. Я думаю, что преимущества свойств явно перевешивают проблемы.

Я не могу не выбрать детали мнений Jeffrey Richter:

Свойство может быть только для чтения или только для записи; доступ к полю всегда читаем и перезаписываем.

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

Метод свойства может выдать исключение; доступ к полю никогда не выдает исключение.

Неправильно: реализация класса может изменить модификатор доступа поля от общественности к частному. Попытки считать частные поля во времени выполнения будут всегда приводить к исключению.

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

Я не соглашаюсь с Jeffrey Richter, но я могу предположить, почему ему не нравятся свойства (я не прочитал его книгу).

Даже при том, что, свойства точно так же, как (мудрые реализацией) методы, как пользователь класса, я ожидаю, что его свойства ведут себя "более или менее" как общедоступное поле, например:

• нет никакого трудоемкого операционного продолжения в свойстве, getter/setter
• метод считывания свойства не имеет никаких побочных эффектов (называющий его многократно, не изменяет результат),

К сожалению, я видел свойства, которые не вели себя тот путь. Но проблемой не являются сами свойства, но люди, которые реализовали их. Таким образом, просто требуется некоторое образование.

Есть время, когда я рассматриваю не использование свойств, и это при написании кода .Net Compact Framework. JIT-компилятор CF не выполняет ту же оптимизацию, что и JIT-компилятор рабочего стола, и не оптимизирует простые методы доступа к свойствам, поэтому в этом случае добавление простого свойства вызывает небольшое увеличение объема кода по сравнению с использованием открытого поля. Обычно это не является проблемой, но почти всегда в мире Compact Framework вы сталкиваетесь с жесткими ограничениями памяти, поэтому даже небольшая экономия, как эта, имеет значение.

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

Однажды я увидел свойство, называемое чем-то вроде клиентов, которое внутренне открыло внепроцессный вызов базы данных и прочитало список клиентов. В клиентском коде было 'for (int i to Customers.Count)', которое вызывало отдельный вызов базы данных на каждой итерации и для доступа выбранного клиента. Это вопиющий пример, демонстрирующий принцип сохранения свойства очень легким - редко больше, чем доступ к внутреннему полю.

Один аргумент ЗА использование свойств состоит в том, что они позволяют вам проверять установленное значение. Другой заключается в том, что значением свойства может быть производное значение, а не отдельное поле, например TotalValue = количество * количество.