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

https://stackoverflow.com/questions/295104

08-07-2019
|

Вопрос

Что отличает поле от свойства в C# и когда следует использовать поле вместо свойства?

Решение

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

public class MyClass
{
    // this is a field.  It is private to your class and stores the actual data.
    private string _myField;

    // this is a property. When accessed it uses the underlying field,
    // but only exposes the contract, which will not be affected by the underlying field
    public string MyProperty
    {
        get
        {
            return _myField;
        }
        set
        {
            _myField = value;
        }
    }

    // This is an AutoProperty (C# 3.0 and higher) - which is a shorthand syntax
    // used to generate a private field for you
    public int AnotherProperty{get;set;} 
}

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

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

Другие советы

Принципы объектно-ориентированного программирования говорят о том, что внутренняя работа класса должна быть скрыта от внешнего мира. Если вы выставляете поле, вы, по сути, выставляете внутреннюю реализацию класса. Поэтому мы заключаем поля в свойства (или методы в случае Java), чтобы дать нам возможность изменить реализацию, не нарушая код в зависимости от нас. То, как мы можем поместить логику в Свойство, также позволяет нам выполнять логику проверки и т. Д., Если нам это нужно. C # 3 имеет, возможно, запутывающее представление об авто свойствах. Это позволяет нам просто определить свойство, и компилятор C # 3 сгенерирует для нас приватное поле.

public class Person
{
   private string _name;

   public string Name
   {
      get
      {
         return _name;
      }
      set
      {
         _name = value;
      }
   }
   public int Age{get;set;} //AutoProperty generates private field for us
}

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

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

Ленивая инициализация: Если у вас есть свойство объекта, загрузка которого требует больших затрат, но к которому не так часто обращаются при обычном выполнении кода, вы можете отложить его загрузку с помощью этого свойства.Таким образом, он просто сидит там, но в первый раз, когда другой модуль пытается вызвать это свойство, он проверяет, имеет ли базовое поле значение null — если да, то он продолжает и загружает его, неизвестное вызывающему модулю.Это может значительно ускорить инициализацию объекта.
Грязное отслеживание: О чем я собственно и узнал от своего собственный вопрос здесь, на StackOverflow.Если у меня есть много объектов, значения которых могли измениться во время выполнения, я могу использовать это свойство, чтобы отслеживать, нужно ли их сохранять обратно в базу данных или нет.Если ни одно свойство объекта не изменилось, флаг IsDirty не сработает, и поэтому функция сохранения пропустит его при принятии решения о том, что необходимо вернуть в базу данных.

Используя Свойства, вы можете генерировать событие, когда значение свойства изменяется (aka. PropertyChangedEvent) или перед изменением значения для поддержки отмены.

Это невозможно с полями (прямой доступ).

public class Person {
 private string _name;

 public event EventHandler NameChanging;     
 public event EventHandler NameChanged;

 public string Name{
  get
  {
     return _name;
  }
  set
  {
     OnNameChanging();
     _name = value;
     OnNameChanged();
  }
 }

 private void OnNameChanging(){
   EventHandler localEvent = NameChanging;
   if (localEvent != null) {
     localEvent(this,EventArgs.Empty);
   }
 }

 private void OnNameChanged(){
   EventHandler localEvent = NameChanged;
   if (localEvent != null) {
     localEvent(this,EventArgs.Empty);
   }
 }
}

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

1.Свойства позволяют установить уровень доступа только для чтения.

Рассмотрим случай dataTable.Rows.Count и dataTable.Columns[i].Caption.Они пришли из класса DataTable и оба общедоступны для нас.Разница в уровне доступа к ним заключается в том, что мы не можем установить значение dataTable.Rows.Count но мы можем читать и писать dataTable.Columns[i].Caption.Возможно ли это через Field?Нет!!!Это можно сделать с помощью Properties только.

public class DataTable
{
    public class Rows
    {       
       private string _count;        

       // This Count will be accessable to us but have used only "get" ie, readonly
       public int Count
       {
           get
           {
              return _count;
           }       
       }
    } 

    public class Columns
    {
        private string _caption;        

        // Used both "get" and "set" ie, readable and writable
        public string Caption
        {
           get
           {
              return _caption;
           }
           set
           {
              _caption = value;
           }
       }       
    } 
}

2.Свойства в PropertyGrid

Возможно, вы работали с Button в Visual Studio.Его свойства показаны на PropertyGrid нравиться Text,Name и т. д.Когда мы перетаскиваем кнопку и нажимаем свойства, она автоматически находит класс. Button и фильтры Properties и покажи это в PropertyGrid (где PropertyGrid не покажет Field хотя они публичные).

public class Button
{
    private string _text;        
    private string _name;
    private string _someProperty;

    public string Text
    {
        get
        {
           return _text;
        }
        set
        {
           _text = value;
        }
   } 

   public string Name
   {
        get
        {
           return _name;
        }
        set
        {
           _name = value;
        }
   } 

   [Browsable(false)]
   public string SomeProperty
   {
        get
        {
           return _someProperty;
        }
        set
        {
           _someProperty= value;
        }
   }

В PropertyGrid, свойства Name и Text будет показано, но не SomeProperty.Почему???Поскольку свойства могут принять Атрибуты.Он не отображается в случае, если [Browsable(false)] является ложным.

3.Может выполнять инструкции внутри свойств.

public class Rows
{       
    private string _count;        


    public int Count
    {
        get
        {
           return CalculateNoOfRows();
        }  
    } 

    public int CalculateNoOfRows()
    {
         // Calculation here and finally set the value to _count
         return _count;
    }
}

4.В источнике привязки можно использовать только свойства.

Источник привязки помогает нам уменьшить количество строк кода. Fields не принимаются BindingSource.Мы должны использовать Properties для этого.

5.Режим отладки

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

   public string Name
   {
        // Can set debug mode inside get or set
        get
        {
           return _name;
        }
        set
        {
           _name = value;
        }
   }

РАЗЛИЧИЯ – ИСПОЛЬЗОВАНИЕ (когда и почему)

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

А свойство — это член, предоставляющий гибкий механизм для чтения, записи или вычисления значения частного поля.Свойства можно использовать так, как если бы они были членами общедоступных данных, но на самом деле это специальные методы, называемые средства доступа.Это обеспечивает легкий доступ к данным и одновременно способствует продвижению безопасность и гибкость методов.Свойства позволяют классу предоставлять общедоступный способ получения и установки значений, скрывая при этом код реализации или проверки.Метод доступа get используется для возврата значения свойства, а метод доступа set используется для присвоения нового значения.

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

Если вы пишете библиотеку классов, предназначенную для широкого потребления (например, .NET Framework, которой пользуются миллионы людей), это может стать проблемой. Однако, если вы пишете класс, используемый внутри небольшой кодовой базы (скажем, & Lt; = 50 тыс. Строк), это на самом деле не имеет большого значения, потому что ваши изменения ни на кого не повлияют. В этом случае все сводится к личным предпочтениям.

Свойства поддерживают асимметричный доступ, т. е. вы можете иметь либо геттер и сеттер, либо просто один из двух. Точно так же свойства поддерживают индивидуальную доступность для getter / setter. Поля всегда симметричны, т.е. вы всегда можете получить и установить значение. Исключением являются поля только для чтения, которые, очевидно, не могут быть установлены после инициализации.

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

Поля могут использоваться для параметров out / ref, свойства - нет. Свойства поддерживают дополнительную логику & # 8211; это может быть использовано для реализации отложенной загрузки среди других вещей.

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

Используйте свойства в большинстве случаев, но старайтесь избегать побочных эффектов.

В фоновом режиме свойство компилируется в методы. Таким образом, свойство Name компилируется в get_Name() и set_Name(string value). Вы можете увидеть это, если изучите скомпилированный код. Таким образом, при их использовании возникают (очень) небольшие потери производительности. Обычно вы всегда будете использовать свойство, если открываете поле извне, и часто будете использовать его внутренне, если вам нужно проверить значение.

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

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

вот демо

class Employee
{
    // Private Fields for Employee
    private int id;
    private string name;

    //Property for id variable/field
    public int EmployeeId
    {
       get
       {
          return id;
       }
       set
       {
          id = value;
       }
    }

    //Property for name variable/field
    public string EmployeeName
    {
       get
       {
          return name;
       }
       set
       {
          name = value;
       }
   }
}

class MyMain
{
    public static void Main(string [] args)
    {
       Employee aEmployee = new Employee();
       aEmployee.EmployeeId = 101;
       aEmployee.EmployeeName = "Sundaran S";
    }
}

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

В целом, все остальные ответы на тему хорошего дизайна: предпочитайте выставлять свойства, а не выставлять поля. Хотя вы, вероятно, не будете регулярно говорить, что & "Вау", представьте себе, насколько хуже было бы, если бы я сделал это поле вместо свойства & Quot ;, это < strong> гораздо реже можно вспомнить ситуацию, когда вы скажете & "вау, слава Богу, я использовал здесь поле вместо свойства. "

Но у полей есть одно преимущество перед свойствами, и это их возможность использовать как " ref " / " out " параметры. Предположим, у вас есть метод со следующей подписью:

public void TransformPoint(ref double x, ref double y);

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

System.Windows.Point[] points = new Point[1000000];
Initialize(points);

Вот я думаю, что самый быстрый способ сделать это, так как X и Y являются свойствами:

for (int i = 0; i < points.Length; i++)
{
    double x = points[i].X;
    double y = points[i].Y;
    TransformPoint(ref x, ref y);
    points[i].X = x;
    points[i].Y = y;
}

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

internal struct MyPoint
{
    internal double X;
    internal double Y;
}

// ...

MyPoint[] points = new MyPoint[1000000];
Initialize(points);

// ...

for (int i = 0; i < points.Length; i++)
{
    TransformPoint(ref points[i].X, ref points[i].Y);
}

Выполняя некоторые измерения , версия с полями занимает примерно 61% времени, так как версия со свойствами (.NET 4.6, Windows 7, x64, режим выпуска, без отладчика). Чем дороже становится метод TransformPoint, тем меньше становится разница. Чтобы повторить это самостоятельно, бегите с закомментированной первой строкой и без закомментированной.

Даже если вышеописанного не было выигрыша в производительности, есть и другие места, где возможность использования параметров ref и out может быть полезной, например, при вызове Interlocked или Семейство методов Volatile . Примечание. В случае, если это для вас новость, Volatile - это, по сути, способ добиться того же поведения, которое обеспечивает ключевое слово volatile. Таким образом, как и <=>, он волшебным образом не решает всех проблем безопасности потоков, так как его название предполагает, что это возможно.

Я определенно не хочу показаться, что я выступаю за то, чтобы вы пошли & "О, я должен начать выставлять поля вместо свойств. " Дело в том, что если вам нужно регулярно использовать этих участников в вызовах, которые принимают & Quot; ref & Quot; или " out " Для параметров, особенно для чего-то, что может быть простым типом значения, которому вряд ли когда-либо понадобится какой-либо из элементов свойств с добавленной стоимостью, можно задать аргумент.

Кроме того, свойства позволяют использовать логику при настройке значений.

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

Действительно полезная функция.

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

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

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

get { return _afield; }
set { _afield = value; }

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

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

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

На этой странице MSDN есть сравнение и советы, которые следует использовать, когда:

https://msdn.microsoft.com /en-us/library/9d65as2e(v=vs.90).aspx

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

  class SomeClass
  {
     int numbera; //Field

     //Property 
    public static int numbera { get; set;}

  }

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

IMO, свойства - это просто " SetXXX () " & Quot; & GetXXX () Quot; пары функций / методов / интерфейсов, которые мы использовали ранее, но они более лаконичны и элегантны.

Традиционно закрытые поля устанавливаются через методы получения и установки. Ради меньшего количества кода вы можете использовать свойства для установки полей.

когда у вас есть класс, который " Car " ;. Свойства цвета, формы.

Где в качестве полей - переменные, определенные в области видимости класса.

Из Википедии - Объектно-ориентированное программирование :

Объектно-ориентированное программирование (ООП) - это парадигма программирования, основанная на концепции & объектов & ", которые представляют собой структуры данных, которые содержат данные в форме полей , часто известный как атрибуты; и код в форме процедур, часто называемых методами . (выделение добавлено)

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

Мой дизайн поля заключается в том, что поле должно быть изменено только его родителем, следовательно, классом. В результате переменная становится закрытой, чтобы иметь возможность дать право читать классы / методы за ее пределами, я прохожу через систему свойств только с Get. Затем поле извлекается свойством и доступно только для чтения! Если вы хотите изменить его, вы должны пройти через методы (например, конструктор), и я считаю, что благодаря этому способу обеспечения вашей безопасности мы можем лучше контролировать наш код, потому что мы & Quot; flange & Quot ;. Можно было бы всегда все обнародовать, поэтому каждый возможный случай, понятие переменных / методов / классов и т. Д. ... на мой взгляд, это просто помощь в разработке, поддержке кода. Например, если человек возобновляет код с открытыми полями, он может делать все что угодно и, следовательно, что-то & Quot; illogical & Quot; по отношению к цели, логика того, почему код был написан. Это моя точка зрения.

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

Вот почему мой старый классический стиль программирования был:

public class MyClass { private int _id; public int ID { get { return _id; } } public MyClass(int id) { _id = id; } }

Мой новый стиль программирования:

public class MyClass { public int ID { get; private set; } public MyClass(int id) { ID = id; } }

Поля - это переменные в классах. Поля - это данные, которые вы можете инкапсулировать с помощью модификаторов доступа.

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

В отличие от поля свойство имеет специальный синтаксис, который контролирует, как человек читает данные и записывает данные, они известны как операторы get и set. Заданную логику часто можно использовать для проверки.

Свойства — это особый вид членов класса. В свойствах мы используем предопределенный метод Set или Get. Они используют средства доступа, с помощью которых мы можем читать, записывать или изменять значения частных полей.

Например, возьмем класс с именем Employee, с частными полями для имени, возраста и идентификатора сотрудника.Мы не можем получить доступ к этим полям снаружи класса, но можем получить доступ к этим частным полям через свойства.

Почему мы используем свойства?

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

Чтобы ясно понять это на примере, давайте возьмем класс учеников, у которых есть идентификатор, пароль и имя.Теперь в этом примере возникла проблема с публичным полем.

Идентификатор не должен быть -ve.

Имя не может быть установлено в ноль

Знак прохождения должен быть доступен только для чтения.

Если имя учащегося отсутствует, следует вернуть No Name.

Чтобы устранить эту проблему, мы используем метод Get и set.

// A simple example public class student { public int ID; public int passmark; public string name; } public class Program { public static void Main(string[] args) { student s1 = new student(); s1.ID = -101; // here ID can't be -ve s1.Name = null ; // here Name can't be null } }

Теперь мы возьмем пример метода get и set.

public class student { private int _ID; private int _passmark; private string_name ; // for id property public void SetID(int ID) { if(ID<=0) { throw new exception("student ID should be greater then 0"); } this._ID = ID; } public int getID() { return_ID; } } public class programme { public static void main() { student s1 = new student (); s1.SetID(101); } // Like this we also can use for Name property public void SetName(string Name) { if(string.IsNullOrEmpty(Name)) { throw new exeception("name can not be null"); } this._Name = Name; } public string GetName() { if( string.IsNullOrEmpty(This.Name)) { return "No Name"; } else { return this._name; } } // Like this we also can use for Passmark property public int Getpassmark() { return this._passmark; } }

Свойства используются для выставления поля. Они используют методы доступа (set, get), через которые можно читать, записывать или манипулировать значениями приватных полей.

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

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

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

Мы можем сделать это двумя способами, используя getter и setters и используя свойство.

Using Getter and Setter // field private int _age; // setter public void set(int age){ if (age <=0) throw new Exception(); this._age = age; } // getter public int get (){ return this._age; } Now using property we can do the same thing. In the value is a key word private int _age; public int Age{ get{ return this._age; } set{ if (value <= 0) throw new Exception() } }

Автоматически реализованное свойство, если мы не используем логику в методах get и set, мы можем использовать автоматически внедренное свойство.
Когда se автоматически внедряет компиляцию свойств, создает закрытое анонимное поле , к которому можно получить доступ только через методы доступа get и set.

public int Age{get;set;}

Абстрактные свойства Абстрактный класс может иметь абстрактное свойство, которое должно быть реализовано в производном классе

public abstract class Person { public abstract string Name { get; set; } public abstract int Age { get; set; } } // overriden something like this // Declare a Name property of type string: public override string Name { get { return name; } set { name = value; } }

Мы можем установить частную собственность В этом мы можем установить свойство auto в личном режиме (устанавливается с помощью класса)

public int MyProperty { get; private set; }

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

private int myProperty; public int MyProperty { get { return myProperty; } }

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

class Room { public string sectionOne; public string sectionTwo; } Room r = new Room(); r.sectionOne = "enter";

Люди довольно легко попадают в раздел. Никаких проверок не было

class Room { private string sectionOne; private string sectionTwo; public string SectionOne { get { return sectionOne; } set { sectionOne = Check(value); } } } Room r = new Room(); r.SectionOne = "enter";

Теперь вы проверили этого человека и узнали, есть ли у него что-то плохое

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

Защитите все эти переменные соответствующими свойствами, которые позволяют вам определять: установи и получи средства доступа и выполнять такие действия, как проверка, когда вы манипулируете этими фрагментами данных.

Но в других случаях, например Класс математики (Системное пространство имен), в класс встроено несколько статических свойств.одна из которых является математической константой ПИ

например.Матем.ПИ

и поскольку PI — это четко определенный фрагмент данных, нам не нужно иметь несколько копий PI, оно всегда будет иметь одно и то же значение.Таким образом, статические переменные иногда используются для совместного использования данных между объектами класса, но они также часто используются для постоянной информации, когда вам нужна только одна копия фрагмента данных.

Основное и общее отличие:

Поля

ВСЕГДА предоставить доступ как для получения, так и для установки

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

Характеристики

НЕ ВСЕГДА предоставить доступ как для получения, так и для установки

МОЖЕТ вызывать побочные эффекты

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow