Какова лучшая практика для использования общедоступных полей?

, Какова лучшая практика для использования общедоступных полей?

“Don’t. ” Видят также: Должен защищенные атрибуты всегда быть запрещенным? , который касается защищенных полей, но что сказано, там еще более верно для общедоступных.

Используйте свойства. Это легко теперь, когда C# имеет Автоматические Свойства !

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

я уверен, что существует больше причин, но те два всегда, кажется, достаточно для меня.

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

Вот хорошая статья об этом:

http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx

Я рекомендую использовать что-то подобное этому:

public class Result{  
    public bool Result {  get; protected set; }
    public string Message {  get; protected set; }

    public Result(bool result, string message) {
        Result = result;
        Message = message;
    }
}

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

На языках C-стиля (как C#) необходимо представить поля через свойства. Это также принадлежит VB.NET и другим языкам.NET, а также они совместно используют тот же базовый механизм. Главная причина сделать это - то, что

Общественность MyField как Целое число НЕ РАВНЯЕТСЯ Общественной собственности MyField как Целое число, у Них нет того же поведения во всей ситуации под.NET.

Однако Вы будете, вероятно, видеть много людей, продолжающих обнародовать Поля. Часть этого происходит из-за того, как VB6 обрабатывает COM. В Общественности VB6 MyField, поскольку Целое число эквивалентно Общественной собственности MyField как Целое число. Поскольку, когда оба переводятся в COM typelib, они оба реализованы таким же образом.

Это привело к большому количеству нечетных ограничений в VB6 по тому, что могло быть общедоступным полем. Ограничения, которые не находятся в.NET и большом количестве других Объектно-ориентированных языков. Эти ограничения пойманы во время компиляции, так препятствуйте тому, чтобы программист стрелял себе в ногу так сказать. Если Ваш класс был частным в VB6 некоторые из них, ограничение, но не все, было упрощено. Общее правило состояло в том, что Вы могли только представить классы и типы данных как общедоступные поля.

наследие VB6 означает, что существует партия программистов, которые не знают, что существует различие в.NET.

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

Этот статья (указанный другими) объясняет сторону.NET его.

, Каково различие между Полем и Свойством в C#?

Я хотел бы ответить на Вашем подходе только для чтения.

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

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

private readonly int result;
private readonly int message;

public Result(bool result, string message)
{
   this.result = result;
   this.message = message;
}

public int Result
{
   get{ return result; }
   private set { result = value; }
}

public int Message
{
   get{ return message; }
   private set { message = value; }
}

Тот способ, которым Вы можете только считать Результат и обмениваться сообщениями и можете все еще записать в него из класса.

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

РЕДАКТИРОВАНИЕ : После чтения кода я сделал на основе того, что было дано в вопросе существует некоторая ошибка, где Результат Имени класса, вероятно, бросит ошибку со свойством Result и также фактом, мы получают bool как результат и строку как сообщение в конструкторе, но пытаются отправить им в интервале этот, будет definatly не работать. Но если это имеет значение вот является что-то логикой гумуса:

private readonly bool result;
private readonly string message;

public Answer(bool result, string message)
{
   this.result = result;
   this.message = message;
}

public bool Result
{
   get{ return result; }
   private set { result = value; }
}

public string Message
{
   get{ return message; }
   private set { message = value; }
}

Ответ, который я даю, - то, что Свойства, больше Осуществляют рефакторинг дружественный.

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

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