Дизайн OO - Вы используете общественные собственности или частные поля внутренне? [дубликат]

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

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

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

Но в целом, я бы сказал, доступ через свойство.

РЕДАКТИРОВАТЬ

Пример (тривиальный / надуманный)

public class Person
{
    private string _name = "";
    private List<String> oldnames = new ArrayList();

    public string Name
    {
        get { return _name; }
        set 
        {
           oldnames.Add(_name);
           _name = value; 
        }
    }

    public Person(string name)
    {
        _name = name; //should I use the property or field here?
    }
}

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

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

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

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

public class MyClass
{
    private string _MyProperty;

    public MyProperty { get { return _MyProperty; } }

    public MyClass ()
    {
        _MyProperty = SomeVeryComplexPropertyInitializationLogic ();
    }
}

Обычно я использую общедоступные свойства с некоторыми исключениями, где я могу захотеть избежать любого дополнительного кода, написанного в методе доступа к свойствам. Благодаря автоматическим свойствам в C # 3.0 я редко создаю вспомогательные поля вручную; как правило, только когда значение по умолчанию для поля автоматического резервного копирования не подходит для моего свойства.

Если вы используете имя поля, вы не получите инкапсуляцию. Инкапсуляция применяется не только между классами, но и внутри класса.

Если в какой-то момент в будущем вы переопределите поле, но оставите подписи функции доступа / установщика такими же, не только внешние классы, которые используют ваш класс, не сломаются, но Внутренние процедуры в вашем собственном классе тоже не сломаются.

Возьмем, к примеру, этот код, свободно основанный на коде, который отображается в платформе Apache Wicket (хотя эта среда не страдает этой проблемой; я просто использую ее для иллюстрации):

Допустим, это был оригинальный учебный класс:

class RadioChoice {
  private String prefix;

  RadioChoice( String prefix ) {
    this.prefix = prefix ;

  setPrefix( String prefix )  {
    this.prefix = prefix ;
   }
}

Здесь мы уже видим проблему: та же самая операция this.prefix = prefix происходит в местах буксировки. Он предназначен для того, чтобы делать одно и то же, но поскольку это происходит в двух местах, это «одно и то же» может расходиться в две разные вещи. (Сравните это с нормализацией базы данных, практикой, предназначенной для предотвращения именно этого.)

Теперь у Apache Wicket есть концепция записи изменений в том, как он отображает веб-страницы, так что эти изменения могут быть отменены. Это делается путем сохранения списка «отмененных» объектов. Префикс RadioChoice - это одна из тех вещей, которые можно отменить, и поэтому установщик 'prefix' должен записать изменение:

class RadioChoice {
  private String prefix;

  RadioChoice( String prefix ) {
    this.prefix = prefix ;

  setPrefix( String prefix )  {
    // save the old prefix
    this.getPage().addChange( new PrefixChange( this.prefix ) );
    // set the new one
    this.prefix = prefix ;
   }
}

Теперь посмотрим, что произойдет: поскольку конструктор устанавливает префикс напрямую, ctor не сохраняет никаких изменений. Если бы мы использовали установщик, ctor бы автоматически " В целом, использование сеттеров и геттеров защищает вас от изменений.

Использовать недвижимость. Или еще лучше, если вы используете C # 3.0 или выше, используйте автоматические свойства, например, так:

public class Person
{
    public string Name { get; set; }

    public Person(string name)
    {
        Name = name; //should I use the property or field here?
    }
}

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

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

По крайней мере в Java нет НИКАКОГО способа использовать открытые поля, потому что старые добрые соглашения javabeans, которые кажутся всем использовать. Я думаю, что C # имеет свойства в качестве конструкций первого языка. Я бы пошел на это

Это зависит. Иногда вы будете писать геттеры / сеттеры, которые выполняют важную предварительную обработку для любого реалистичного взаимодействия с полем. Например, если строковое поле имеет ограничение на то, что оно всегда должно быть в нижнем регистре, то по крайней мере один из ваших методов getter / setter должен вызвать .ToLower () или .ToLowerInvariant (), и в коде вашего класса вы, вероятно, Я хочу использовать это, чтобы убедиться, что ограничение применено.

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

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

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