Руководство по стилю для предотвращения нежелательного доступа к полю

#c# #properties #coding-style #field

#c# #свойства #стиль кодирования #поле

Вопрос:

Однажды я видел здесь вопрос о том, возможно ли встроить поля в свойства, чтобы к ним нельзя было получить доступ в остальной части класса, например

 public string Name
{
    private string _name;

    get { return _name; }
    set
    {
        _name = value;
        // <Important stuff that would not be executed
        //  upon direct field access>
    }
}
  

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

 private int _progress = 0;
private int progress
{
    get { return _progress; }
    set { _progress = value; }
}
  

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

Итак, мой вопрос — или, скорее, вопросы, это:

Это хорошая идея?
Разумно ли использовать camel-case для частных свойств?
Может ли кто-нибудь придумать сценарий, в котором это может оказаться проблематичным?

Ответ №1:

Если средство получения и установки не имеет побочных эффектов, нет смысла создавать частное свойство для переноса частного поля. Либо используйте поле и покончите с этим, либо используйте автоматическое свойство. Не пишите шесть строк кода, чтобы выразить смысл одной строки; вы просто усложняете чтение вашего кода.

Теперь, если у вашего установщика действительно были побочные эффекты, тогда это другое дело. В этом случае неплохо иметь руководство о том, что вы не должны устанавливать поле вне свойства — но учтите, что конструктору, возможно, потребуется также установить это поле. (Первоначальная настройка состояния объекта может потребовать обхода побочных эффектов.) Также могут быть другие случаи, когда вы хотите использовать поле (глубокое копирование, загрузка / сохранение и т.д.), Но именно поэтому «использовать свойство» должно быть руководством, а не жестким правилом: вы хотите немного подумать, прежде чем обходить свойство.

Что касается соглашений об именовании, очевидно, это зависит от вас, но мне кажется очень странным иметь свойство camelCased. Во всем коде, который я видел, свойства обрабатываются с помощью PascalCased, даже если они являются частными.

Комментарии:

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

2. @H.B: Я думаю, вы напрасно усложняете свой код, не получая за это многого, то, что у вас есть, должно быть свойством auto imo.