Вы должны получить доступ к переменной в том же классе через свойство?

Question

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

Мой вопрос: вы должны всегда делать это в классе? Я всегда использовал Свойство, если оно есть, даже в классе, но хотел бы услышать некоторые аргументы за и против того, какой из них наиболее правильный и почему.

Или это просто вопрос стандартов кодирования, используемых в проекте?

Answer 1

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

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

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

С введением автоматических свойств стало еще меньше причин явно указывать локальную переменную, если только вам не нужно применять бизнес-правила к get / set

Answer 2

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

Когда вы идете прямо в приватное поле, вы знаете, что поле настроено именно на то, что вы говорите.

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

Довольно сложно придумать правило о том, что выполнение того или иного «правильного», единственное, что я бы сказал, что следую, это то, что при инициализации конструктора я почти никогда не буду использовать Свойство.

Answer 3

Всегда используйте свойства, вот некоторые из причин

1. Простота в использовании. В Visual Studio вы можете использовать «Prop Tab Tab». Вы получите фрагмент объекта
2. Свойства - это языковые элементы, доступ к которым осуществляется так, как будто они являются элементами данных
3. .NET Framework использует классы, классы кода привязки данных в свойствах поддержки .NET Framework,
4. Свойства имеют все языковые особенности методов. Свойства могут быть виртуальными

Answer 4

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

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

class Test {
   private int _checksum = -1;
   private int Checksum {
      get {
         if (_checksum == -1)
            _checksum = calculateChecksum();
         return checksum;
      }
   }
}

Answer 5

Обычно, в зависимости от стандартов кодирования проекта, я использую «_» или «m», предшествующие имени для моих атрибутов частного класса. (Как показано ниже)

private int mVariable;
private int _Variable;

С теми, кто стоит перед переменной, я сразу понимаю, что имею дело с внутренней переменной для класса. Затем, когда дело доходит до отладки позже, я или кто-то другой может сразу же распознать, что код имеет дело с внутренней частной переменной, и выполнить настройку. Так что все сводится к читабельности для меня.

Answer 6

Я думаю, что это чисто предпочтение.

Хотя в C # 3.0 я гораздо больше использую свойства с поддержкой авто-свойств:

class Foo {
    public string Value { get; set; }

    public void Write() {
        Console.Write(Value);
    }
}