Использование свойств по сравнению с полем поддержки внутренний класс владельца
Я люблю автореализованные свойства в C#, но в последнее время был этот слон, стоящий в моей кабине, и я не знаю, что сделать с ним.
Если я использую автореализованные свойства (после этого "aip") затем, у меня больше нет частного поля поддержки для использования внутренне. Это прекрасно, потому что aip не имеет никаких побочных эффектов. Но что, если позже я должен включить некоторую дополнительную обработку получения или установить?
Теперь я должен создать поле поддержки, таким образом, я могу развернуть свои методы считывания и методы set. Это хорошо для внешнего кода с помощью класса, потому что они не заметят различия. Но теперь все внутренние ссылки к aip собираются вызвать эти побочные эффекты, когда они получают доступ к свойству. Теперь весь внутренний доступ к однажды aip должен быть пересмотрен для использования поля поддержки.
Таким образом, мой вопрос, что делает большинство из Вас? Вы используете автореализованные свойства, или Вы предпочитаете всегда использовать поле поддержки? Что Вы думаете о свойствах с побочными эффектами?
5 ответов
У Эрика Липперта есть отличная статья в блоге, которая отвечает на этот вопрос:
Если причина, которая побудила переход от автоматически реализуемого свойств к явно реализованным свойство, было изменение семантики свойства, то вам следует оценить, будет ли желаемая семантика при доступе к свойству из внутри класса идентична или отличается от желаемой семантики при доступе к свойству из вне класса.
Если результатом этого исследования является. "изнутри класса желаемая семантика доступа к этому свойству отличается от желаемой семантики доступа к этому свойству извне", то ваша правка ввела ошибку. Вам следует исправить ошибку. Если они одинаковы, то ваша правка не привела к ошибке; оставьте реализацию прежней.
С точки зрения отделения команд от вопросов, имея свойства со стороной -эффекты не так уж и хороши. Я бы предпочел, чтобы мои объекты отвечали на вопросы таким же образом, пока я не вызвал никаких методов, которые четко заявляют, что что-то может измениться.
Я не вижу проблем с использованием автоматически реализуемых свойств. представьте, что у вас есть какое-то свойство:
public string Name
{
get; set;
}
Если вам понадобится дополнительная обработка в будущем, вы просто измените свое свойство:
private string name;
public string Name
{
get { return this.name; }
set
{
if (!string.IsNullOrEmpty(value))
{
this.name = value;
}
}
}
Прежде всего, геттеры свойств не должны иметь побочных эффектов . Это не всегда так, но у вас должна быть очень веская причина, по которой это не так.
При этом получить список ссылок на свойство тривиально. Если вы переходите на явное свойство и хотите, чтобы ваш частный код имел доступ к вашей новой резервной переменной, это должно быть довольно легко сделать.
Я всегда использую AIP, пока мне не понадобится вспомогательное поле. Просто поменять местами:
public string MyString{get;set;}
на
private string myString;
public string MyString{get{return myString;} set{myString = value;}}
не очень сложно. Я думаю, что всегда использовать последнее - ненужный беспорядок.