Почему когда-нибудь используют поля вместо свойств?

Синтаксис для полей намного быстрее для записи, чем для свойств, поэтому, когда он безопасен использовать поле (частное для класса), почему бы не использовать его и сохранить эту дополнительную набрать? Если автоматически реализованные свойства имели хороший короткий краткий синтаксис, и вам пришлось сделать дополнительную работу, чтобы сделать простое старое поле, люди могут просто начать использовать свойства вместо этого. Также это конвенция сейчас в C #. Вот как люди думают, и это то, что они ожидают увидеть в коде. Если вы сделаете что-то другое, формуют нормально, вы будете путать всех.

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

Существует очень простая причина, по которой нам все еще нужно иметь явные поля:

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

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

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

Я не понимаю, почему вы используете Частные автопроверсии. Какое преимущество в

private int Count {get; set;}

над

private int count

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

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

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

Существует № причина публично выставлять поля.

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

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

Если вы хотите иметь что-то readly , вам в значительной степени необходимо использовать поле, так как нет способа сказать автоматическое свойство для создания поля только для чтения.

Я делаю это довольно часто.

Надуманный пример:

class Rectangle
{
   private readonly int _width;
   private readonly int _height;

   public Rectangle(int width, int height)
   {
      _width = width;
      _height = height;
   }

   public int Width { get { return _width; } }
   public int Height { get { return _height; } }
}

Это означает, что ничего не означает, что внутри прямоугольника не может изменить ширину или высоту после строительства. Если кто-то пытается компилятору, будет жаловаться.

Если я вместо этого использовал автоматическое свойство с частным сеттером, компилятор не защитит меня от себя.

Еще одна причина, по которой я вижу, это, если часть данных не должна быть выставлена ​​(пребывание частных ) Почему сделать его свойством?

В то время как я согласен с тем, что я воспринимаю как «намерение» в заявлении Дэвида Басараба: «Нет причин публично выставлять поля», - я хотел бы добавить немного разного внимания:

​​Я бы изменил цитату из Дэвида выше, чтобы прочитать: «Нет причин публично выставлять поля ... вне класса ... За исключением сознательного выбора инкапсулирования полей в свойствах, через которые доступен доступом.

Свойства не просто «шпон» синтаксиса над полями «прикреплены к» C #: они являются фундаментальной языковой особенностью, разработанной по причинам, в том числе:

1. , контролируя то, что открывается и не подвергается воздействию внешних классов (инкапсуляция, скрытие данных )

2. , позволяющие выполнять определенные действия, когда доступ к недвижимому имуществу или установлено: действия, которые лучше всего выражены в свойстве «GET и», а не «повышены» для внешних методов.

3. Интерфейсы по дизайну не могут Определите поля: но могут определить свойства.

Хорошая ОО Дизайн означает, что делает сознательный выбор о «штате»:

1. . Локальные переменные поля: то, что состояние является частным для метода и переходных данных : локальные переменные, как правило, действительны только в пределах объема корпуса метода или даже с «Узкая продолжительность жизни» как в пределах объема чего-то вроде «для петли». Конечно, вы можете рассматривать переменные параметров в методе как «локальный».

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

3. Поля статического экземпляра: какое государство будет собственностью только класса, независимо от количества экземпляров класса.

4. Государство намеренно и сознательно выставленные «вне» класса: ключевой идею, что существует, по меньшей мере, один уровень косвествия, вставленного между классом и «потребителями» данных, которые выставляют класс. «Отказ» от «Экспозиции», конечно, сознательное намерение скрывать (инкапсулирующий, изолировать) код реализации.

   а. С помощью общественных свойств: все аспекты этого хорошо освещены во всех других ответах здесь

   b. через индексаторы

   c. через методы

   d. Общественные статические переменные обычно встречаются в коммунальных классах, которые часто являются статическими классами.

Предложить вам обзор: MSDN на полях ... MSDN по свойствам ... MSDN на индексах

поля - единственное место, где вы можете хранить состояние. Свойства на самом деле представляют собой просто пара методов со специальным синтаксисом, который позволяет их сопоставлять с методом Get или Set в зависимости от того, как их используют: если свойство изменяет или доступ к состоянию, то состояние все еще должно быть сохранено в поле Отказ

Вы не всегда видите поля. С помощью автоматических свойств C # 3 поля создается для вас компилятором. Но это все еще там. Кроме того, автоматические свойства имеют некоторые существенные ограничения (например, нет поддержки INOTIFYPROPERTYCHANTY, без бизнес-логики в уставе), что означает, что они часто неуместны, и вам необходимо создать явное поле и вручную и недвижимость.

Согласно Ответ Давида , вы правы, если вы говорите о API: вы почти никогда не хотите сделать внутреннее состояние (поля) часть API.

Как отметили другие, вам все равно понадобится частное поле для недвижимости.

Также имеется преимущество скорости в использовании полей над свойствами. В 99,99% случаев это не имеет значения. Но в некоторых это может.

Поля и свойства не взаимозаменяемы. Я предполагаю, что вы имеете в виду доступ к частным полям через частные свойства. Я делаю это, когда это имеет смысл, но по большей части в этом нет необходимости. Оптимизатор JIT в любом случае будет встраивать доступ к частному полю через частное свойство. И перенос частного поля в частное свойство в любом случае не считается критическим изменением, поскольку частные члены не являются частью вашего интерфейса.

Лично я бы никогда никогда не раскрывал какие-либо защищенные / общедоступные поля экземпляра. Тем не менее, как правило, допустимо предоставлять общедоступное статическое поле с модификатором readonly, если тип поля сам по себе является неизменным. Это часто наблюдается со статическими полями SomeStruct.Empty.

Свойства - замечательная вещь, но есть накладные расходы, связанные с доступом к свойствам. Не обязательно проблема, но о чем нужно знать.

Предотвращение чрезмерного использования средств получения и установки свойств

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

Источник: http://dotnet.sys-con.com/node/46342

Скорость. Если поле устанавливается или считывается миллиарды раз в течение моделирования, то вы хотите использовать поле, а не свойство, чтобы избежать накладных расходов на вызов подпрограмм. В соответствии с ОО (DDD?), насколько это возможно, в таких случаях я бы рекомендовал использовать поля только в классах, предназначенных для представления какого-то "значения", например, человека. Логика должна быть сведена к минимуму. Лучше иметь personcreator или personservicer.

Но если у вас есть такие проблемы, то вы, вероятно, программируете не на c++ и не на c#, не так ли?

Просто попробуйте использовать свойство при использовании аргументов ref / out:

someObject.SomeMethod(ref otherObject.SomeProperty);

Оно не будет компилироваться.