Я должен использовать общественные собственности и частные поля или общедоступные поля для данных?

Вы должны использовать свойства в следующих случаях:

1. Когда вам нужно сериализовать данные в свойстве в некоторый формат.
2. Когда вам нужно переопределить свойства в производном классе.
3. Когда вы реализуете методы get и set с некоторой логикой. Например, когда вы реализуете шаблон Singleton.
4. Когда вы производите от интерфейса, где было объявлено свойство.
5. Когда у вас есть определенные проблемы, связанные с отражением.

Я не могу поверить, что с 11 ответами никто не сказал этого:

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

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

private string _email;
public string Email
{
    get
    {
        return this._email;
    }
    set
    {
        this._email = value;
        ReplaceList(); //**
    }
}

Идея в том, что вы не должны случайно / непреднамеренно изменять значение частного поля класса снаружи. Когда вы используете get и set, это означает, что вы намеренно и сознательно изменяете приватное поле класса.

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

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

Я понял, что когда я попытался объединить имена регионов, которые я использую в Composite Guidance (PRISM).

Однако это всего лишь языковые ограничения и помимо static / const поля Я всегда использую свойства.

Это ... зависит?

Я всегда использую геттеры и сеттеры, поскольку они создали этот ярлык:

public int Foo {get; установлен; }

Во время компиляции он переводится. Теперь вы не можете представить себе это, но он есть, и если вам нужно вообразить, вы просто объясните его позже.

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

protected _foo;  
public Foo  
{  
    get { return _foo; }
} //lack of set intentional.

Что ж, разница есть. Общедоступные данные могут быть изменены без ведома экземпляра объекта. Используя геттеры и сеттеры, объект всегда знает, что было внесено изменение.

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

При создании частного поля имя и простого общедоступного свойства Имя , которое фактически получает и устанавливает значение поля имя

public string Name
{
   get { return name; }
}

, и вы используете это свойство везде за пределами вашего класса, и однажды вы решите, что свойство Name этого класса действительно будет ссылаться на поле lastName (или что вы хотите вернуть string "My name:" + name), вы просто меняете код внутри свойства:

public string Name
{
   get { return lastName; //return "My name: "+name; }
}

Если бы вы использовали публичное поле name везде во внешнем коде, тогда вам пришлось бы изменить name - lastName везде, где вы его использовали.

Три причины:

1. Вы не можете переопределять поля в подклассах, как свойства.
2. В конечном итоге вам может потребоваться более сложный метод получения или установки, но если это поле, его изменение сломать API.
3. Конвенция. Именно так это и делается.

Я уверен, что есть и другие причины, о которых я просто не думаю.

В .Net 3.x вы можете использовать такие автоматические свойства, как это:

public int Age { get; set; }

вместо старый школьный способ, когда вы сами объявляете свои частные поля следующим образом:

private int age;

public int Age
{
    get { return age; }
    set { age = value; }
}

Это делает его таким же простым, как создание поля, но без проблем с критическими изменениями (среди прочего).

Причин тому много.

В основном:

• Вы можете выполнять некоторые другие функции, когда переменная установлена.
• Вы можете запретить установку и предоставить только get
• Некоторые «вещи» работают только со свойствами (например, DataBinding)
• Вы можете скрыть реализацию свойства [возможно, это переменная ViewState в ASP.NET).