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

Извините, если я Noob, у меня есть это сомнение, почему мы используем частные переменные и устанавливаем их с помощью свойств ?

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

Я говорю о таких ситуациях, как эта

private string _testVariable;

public string MyProperty
{
    get { return _testVariable;}
    set {_testVariable = value;}
}

Я думаю просто используя

public string MyProperty { get; set; } 

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

спасибо

9 ответов


ваши примеры семантически одинаковы. Краткий синтаксис объявления свойств (просто имея { get; set; }) - это ярлык, доступный в C# 3.0. Компилятор фактически создает частную переменную поддержки и простой геттер и сеттер, как в вашем первом примере.

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


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

Если все, что вы делаете, это чтение / запись переменной, то нет. В противном случае есть две причины, по которым вам нужна частная переменная:

проверка данных

// Data validation
public class IntWrapper
{
    private int _value;
    public int Value
    {
        get { return _value; }
        set
        {
            if (value < 0) { throw new Exception("Value must be >= 0"); }
            _value = value;
        }
    }
}

Getter / setter завершает базовое хранилище данных

public class StringBuffer
{
    List<char> chars = new List<char>();

    // Wraps up an underlying data store
    public string Value
    {
        get { return new String(chars.ToArray()); }
        set { chars = new List<char>(value.ToCharArray()); }
    }

    public void Write(string s) { Write(chars.Count, s); }

    public void Write(int index, string s)
    {
        if (index > chars.Count) { throw new Exception("Out of Range"); }
        foreach(char c in s)
        {
            if (index < chars.Count) { chars[index] = c; }
            else { chars.Add(c); }
            index++;
        }
    }
}

второй пример, который вы даете:

public string MyProperty { get; set; }

доступно только в более поздних версиях .Net framework (v3.0 вперед я верю)

первый пример позволяет установить точки останова на return и операторы присваивания, вызывающие разрыв отладчика при назначении / чтении свойства.


1-й код СНиП allws вы изменить некоторые состояния частного класса. Обертывание частного состояния в свойство приятно, потому что оно скрывает реализацию. Позже вы можете изменить реализацию, и свойство (внешний интерфейс) может остаться неизменным.

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

свойства auto в вашем 2-м коде snip не связаны с частной переменной вообще. Конструкция auto-property, как и явный дизайн свойств, используемый в первом СНиПе, позволяет в будущем изменять. Например, в рамках этой модификации можно преобразовать свойства auto в явно реализованные свойства.


машешь, Мы все должны были с чего-то начать! Вы спросили о частных vars vs properties с этим ex:

private string _testVariable;

public string MyProperty
{
    get { return _testVariable;}
    set {_testVariable = value;}
}

-or-

public string MyProperty { get; set; }

вы:

public string MyProperty { get; private set; }

вы можете применить область к геттерам/сеттерам свойств . . . . интересный материал. О да. . . при использовании этого типа свойства в определяющем классе (например, в конструкторе) добавьте его с помощью " this.- значит, задание будет выглядеть так.MyProperty = "Назначенная Строка";'. Это делает ваши намерения много более ясным . . .


свойство в основном является оболочкой вокруг поля. Эта оболочка позволяет использовать переменную из внешнего мира. В C#3.0, вы можете просто объявить свойство типа public string MyProperty { get; set; } компилятор автоматически объявляет закрытую переменную и получает методы set для этого. Если вам нужно выполнить какие-либо вычисления внутри класса, объявляющего свойство, для этого следует использовать поле private.


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

Это может быть более актуально в крупных корпоративных приложениях или быстро развивающихся приложениях (agile), где полная реализация может быть неизвестна во время начального кодирования.


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

очевидно, если у вас есть необходимость сделать что-то особенное в геттере или сеттере, то следует использовать полную семантическую форму, а не сахар.

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

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

вы можете получить доступ к переменной поддержки внутри, а также свойство, так что это правильный путь? Это не очевидно...


Это не связано с C# langugage, но больше приложения.

одна из причин использования свойств заключается в том, что она рассматривается как "специальная" во многих фреймворках. Например, Silverlight и WPF будут привязываться к свойствам, а не к полям