Свойства и автоматические реализации
Я использую .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
, но установщик был просто set;
. Он дал мне ошибку: я должен дать набор тела, потому что он не абстрактный или частичный. Почему в этом случае он не будет автоматически реализовывать сеттер для меня?
Наконец, когда я вызываю new в свойствах того же класса, в котором он объявлен, в чем разница между выполнением этого свойства и обычной переменной того же типа? Действительно ли свойства отличаются от переменных в этом случае? Неправильная практика использовать свойства таким образом, когда это должно быть выполнено с помощью частных переменных?
Это могут быть некоторые ошибочные вопросы, но я не могу найти другого места, в котором есть информация, которая поможет мне понять эти различия. Я играю со свойствами, чтобы попытаться понять все это, но я мог бы использовать так, чтобы мне помогали.
Ответы
Ответ 1
Во-первых, есть ли какая-нибудь причина для использования частной собственности?
Обычно нет. Свойства отлично подходят для инкапсуляции. Одно преимущество (есть много больше) использования свойства - это то, что он может выполнять проверки перед назначением. Когда у вас есть что-то private
, вам обычно не нужно защищать вещи от себя. Кроме того, свойства имеют преимущество в настройке разных аксессуаров (private
, protected
и т.д.), Где нет полей.
Почему бы это не было автоматическое внедрение setter для меня в этом случае?
Мы должны понимать, что автоматически реализованные свойства не являются черной магией. Компилятор будет генерировать для нас частное поле поддержки, а не предоставлять один из наших. С его точки зрения, он видит, что у вас есть getter, который возвращает частное поле, но сеттер является автоматическим, что обычно указывает на некоторую логическую ошибку в вашем коде. Почему бы вам вернуть одно значение, но установить совершенно другое? Когда вы создаете свойство с помощью поля поддержки, вы должны предоставить как getter, так и seters, это правила.
когда я вызываю new в свойствах того же класса, что и в чем заключается разница между выполнением этого свойства и нормальная переменная того же типа?
Семантически, ничего. new
принадлежит к типу, который строится и будет вызывать вызов конструктора. Разница заключается в том, что назначается вновь созданный объект. Поле приведет к тому, что компилятор выдает код операции stfld
. Для свойства он испустит call
, чтобы вызвать свойство setter. Когда вы получите доступ к свойству, компилятор завершит вызов get_YourPropertyName
vs a ldfld
в поле.
Неправильная практика использовать свойства таким образом, когда это должно быть с частными переменными?
Я бы не назвал это плохой практикой, но мне было бы немного странно иметь частную собственность.
Дополнительные сведения о полях и свойствах см. в В чем разница между полем и свойством в С#?
Ответ 2
Есть ли причина использовать частную собственность?
Нет - весь смысл автоматической реализации. Это избавляет вас от необходимости писать весь этот дополнительный код, когда все, что вы хотите сделать, - это получить или установить, что в переменной частного члена..Net обрабатывает создание скрытой переменной частного члена за кадром.
Когда я попытался изменить свой код, чтобы использовать переменные, а затем получить к ним доступ через свойства, подобные вашему типичному примеру свойств, я столкнулся с проблемами. Я нашел пример, когда геттер был настроен на возвращение _clientDict, но набор был только установлен; Это дало мне ошибку: я должен дать тело, потому что он не абстрактный или частичный. Почему в этом случае он не будет автоматически реализовывать сеттер для меня?
Я понимаю, что это все или ничего с автоматической реализацией. (Открыто для коррекции, хотя). Тем не менее, я видел компиляцию кода с заданным блоком, который просто определяется как set { }
. Изменить: просто для того, чтобы прояснить блок set { }
на самом деле не установит значение, он по сути проглатывает вызов и ничего не делает - он будет компилироваться, хотя.
Когда я вызываю new в свойствах того же класса, в котором он объявлен, в чем разница между выполнением этого свойства и обычной переменной того же типа? Действительно ли свойства отличаются от переменных в этом случае? Неправильная практика использовать свойства таким образом, когда это должно быть сделано с помощью частных переменных?
Насколько я знаю, нет никакой реальной разницы. То же самое происходит, это просто то, что .Net обрабатывает сантехнику для вас.