Свойства и автоматическая реализация

Question

Я использую .NET 4.5 в добавлении VSTO для Outlook 2013. У меня есть некоторые проблемы с полным пониманием свойств и аксессуаров. Автоматически реализованные аксессоры, которые я предполагаю, когда вы просто пишете get; задавать; а не получать {// code} и т. д., также дают мне проблемы. У меня есть словарь, который я использую внутри себя в своем классе. Вот мой код:

private Dictionary<string, string> clientDict { get; set; } 
private Dictionary<string, string> clientHistoryDict { get; set; } 

затем позже:

clientDict = new Dictionary<string, string>(); 
clientHistoryDict = new Dictionary<string, string>(); 

Я использую те же имена, что и свойства в коде позже, в том же классе.

Я никогда не пишу:

private Dictionary<string, string> _clientDict; // etc. 

создать переменные я просто использовал напрямую.

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

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

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

Во-вторых, когда я попытался изменить свой код, чтобы использовать переменные, а затем получить к ним доступ через свойства, подобные вашему типичному примеру свойств, я столкнулся с проблемами. Я нашел пример, где получатель был установлен в return _clientDict, но сеттер был только Это дало мне ошибку: я должен дать набор тела, потому что он не абстрактный или частичный. Почему в этом случае это не было бы автоматическим установщиком для меня?

Последнее, когда я вызываю new в свойствах того же класса, в котором он объявлен, в чем разница между выполнением этого свойства и обычной переменной того же типа? Действительно ли свойства отличаются от переменных в этом случае? Неправильная практика использовать свойства таким образом, когда это должно быть выполнено с помощью частных переменных?

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

Answer 1

First, is there any reason to use a private property?

Обычно нет. Свойства отличные для инкапсуляция. Одно из преимуществ (есть manymore) использования свойства в том, что он может выполнять проверки перед назначением. Когда у вас есть что-то private, вам обычно не нужно для защиты вещей от себя. Кроме того, свойства имеют преимущество в настройке различных аксессуаров (private, protected и т. Д.), Где полей нет.

Why would it not auto-implement the setter for me in this instance?

Мы должны понимать, что автоматически реализованные свойства не являются черной магией. Компилятор будет генерировать для нас частное поле поддержки, а не предоставлять один из наших.С его точки зрения, он видит, что у вас есть геттер, который возвращает частное поле, но сеттер является автоматическим, что обычно указывает на логическую ошибку в вашем коде. Почему бы вам вернуть одно значение, но установить совершенно другое? Когда вы создаете свойство с помощью поля поддержки, вы должны предоставить как getter, так и seters, those are the rules.

when I call new on the properties in the same class that it is declared in, what is the difference between doing that with a property and a normal variable of the same type?

Семантически Ничего. new принадлежит к типу, который строится и будет вызывать вызов конструктора. Разница заключается в том, что только что созданный объект присвоен. Поле заставит компилятор исправить код операции stfld. Для свойства он выдает call для вызова средства настройки свойств. Когда вы получите имущество, компилятор в конечном итоге вызовет get_YourPropertyName против ldfld на поле.

Is it bad practice to use properties this way when it should be accomplished with private variables?

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

Дополнительные идеи по полям и свойствам, см What is the difference between a Field and a Property in C#?

Answer 2

Is there any reason to use a private property?

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

When I tried to change my code to use variables and then access them via the properties like your typical property example would, I ran into problems. I found an example where the getter was set to return _clientDict, but the setter was just set; It gave me the error: that I must give set a body because it's not abstract or partial. Why would it not auto-implement the setter for me in this instance?

Я понимаю, что это все или ничего с автоматической реализацией. (Открыто для коррекции, хотя). Тем не менее, я видел компиляцию кода с заданным блоком, просто определяемым как set { }. Редактировать: просто для уточнения блока set { } фактически не будет установлено значение, оно по существу проглатывает вызов и ничего не делает - оно будет компилироваться.

When I call new on the properties in the same class that it is declared in, what is the difference between doing that with a property and a normal variable of the same type? Do properties differ at all from variables in that case? Is it bad practice to use properties this way when it should be accomplished with private variables?

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