blocks|key|3123647|text|封装。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3123648|在第二个实例中，您刚刚定义了一个变量，在第一个实例中，变量周围有一个getter+/+setter。因此，如果你决定以后再验证这个变量--这会容易得多。|3123649|此外，它们在Intellisense中的显示方式也不同:)|3123650|编辑:+OPs的更新更新问题-如果你想忽略这里的其他建议，另一个原因是它根本不是很好的面向对象设计。如果你没有很好的理由这样做，总是选择一个属性而不是一个公共变量/字段。|offset|length|style|BOLD|3123651|entityMap^0|0|0|0|0|8|1S|2|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@$H|R|I|S|J|K]|$H|T|I|U|J|K]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|M|$]]

Encapsulation.

In the second instance you've just defined a variable, in the first, there is a getter / setter around the variable. So if you decide you want to validate the variable at a later date - it will be a lot easier.

Plus they show up differently in Intellisense :)

Edit: Update for OPs updated question - if you want to ignore the other suggestions here, the other reason is that it's simply not good OO design. And if you don't have a very good reason for doing it, always choose a property over a public variable / field.

blocks|key|3123688|text|第一个：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3123689|public+string+MyString+{get;+set;+}|code-block|syntax|javascript|3123690|是一个属性；第二个属性(+public+string+MyString+)表示一个字段。|offset|length|style|CODE|3123691|不同之处在于，某些技术(实例的ASP.NET数据绑定)仅适用于属性，而不适用于字段。XML序列化也是如此:只有属性被序列化，字段不被序列化。|3123692|entityMap^0|0|0|D|M|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

The first one:

<pre><code>public string MyString {get; set; }
</code></pre>

is a property; the second one ( <code>public string MyString</code> ) denotes a field.

The difference is, that certain techniques (ASP.NET databinding for instances), only works on properties, and not on fields.
The same is true for XML Serialization: only properties are serialized, fields are not serialized.

blocks|key|3123741|text|几个快速、明显的区别|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3123742|3123743|属性可以有访问者关键字。|ordered-list-item|3123744|3123745|public+string+MyString+{+get；private+set；}|3123746|可以在后代中覆盖属性。|unordered-list-item|3123747|3123748|公共虚拟字符串MyString+{+get；protected+set；}|3123749|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|V|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

A couple quick, obvious differences

<ol>
<li>A property can have accessor keywords.

<pre><code>public string MyString { get; private set; }
</code></pre></li>
<li>A property can be overridden in descendents.

<pre><code>public virtual string MyString { get; protected set; }
</code></pre></li>
</ol>

blocks|key|347829|text|基本区别在于，字段是内存中存储指定类型数据的位置。属性表示为检索或设置指定类型的值而执行的一个或两个代码单元。通过使用行为类似于字段的成员(因为它可以出现在赋值操作的任意一侧)，这些访问器方法的使用在语法上是隐藏的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|347830|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The fundamental difference is that a field is a position in memory where data of the specified type is stored. A property represents one or two units of code that are executed to retrieve or set a value of the specified type. The use of these accessor methods is syntactically hidden by using a member that appears to behave like a field (in that it can appear on either side of an assignment operation).

blocks|key|3336787|text|在许多情况下，属性和字段可能看起来很相似，但事实并非如此。对字段不存在的属性有限制，反之亦然。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3336788|正如其他人提到的那样。您可以将属性设置为只读或只写，方法是将其访问器设置为私有。你不能用一个字段做到这一点。属性也可以是虚拟的，而字段不能。|3336789|可以将属性看作getXXX()/setXXX()函数的语法糖。这就是它们在幕后实现的方式。|3336790|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Properties and Fields may, in many cases, seem similar, but they are not. There are limitations to properties that do not exist for fields, and vice versa.

As others have mentioned. You can make a property read-only or write-only by making it's accessor private. You can't do that with a field. Properties can also be virtual, while fields cannot. 

Think of properties as syntactic sugar for getXXX()/setXXX() functions. This is how they are implemented behind the scenes.

blocks|key|3123955|text|字段和属性看起来是一样的，但它们不是。属性是方法，因此有一些属性不支持的东西，还有一些属性可能会发生但在字段中永远不会发生的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3123956|以下是不同点的列表：|3123957|3123958|字段可用作out/ref参数的输入。属性不能。|unordered-list-item|offset|length|style|CODE|3123959|字段在多次调用时将始终产生相同的结果(如果我们忽略了多线程的问题)。像itself.|3123960|Properties这样的属性并不总是等于that.|3123961|Properties，可能会抛出异常--字段永远不会抛出异常，可能会有副作用，或者执行起来需要很长时间。字段没有副作用，对于给定的类型，其速度总是与预期的一样快。|3123962|属性支持不同的getter/setter可访问性-字段不支持(但字段可以使用反射进行readonly)|3123963|When+)属性和字段被视为不同的MemberTypes，因此它们的位置不同(例如，GetFields和GetProperties+)|3123964|与字段访问相比，JIT编译器可能会以非常不同的方式处理属性访问。然而，它可以编译成相同的本机代码，但差异的范围是存在的。|3123965|3123966|entityMap^0|0|0|0|5|7|0|0|0|0|16|8|0|H|B|16|9|1G|D|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|13|8|@$H|14|I|15|J|K]]|9|@]|A|$]]|$1|L|3|M|5|G|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|G|7|18|8|@]|9|@]|A|$]]|$1|R|3|S|5|G|7|19|8|@$H|1A|I|1B|J|K]]|9|@]|A|$]]|$1|T|3|U|5|G|7|1C|8|@$H|1D|I|1E|J|K]|$H|1F|I|1G|J|K]|$H|1H|I|1I|J|K]]|9|@]|A|$]]|$1|V|3|W|5|G|7|1J|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|Z|$]]

Fields and properties look the same, but they are not. Properties are methods and as such there are certain things that are not supported for properties, and some things that may happen with properties but never in the case of fields. 

Here's a list of differences:

<ul>
<li>Fields can be used as input to <code>out/ref</code> arguments. Properties can not. </li>
<li>A field will always yield the same result when called multiple times (if we leave out issues with multiple threads). A property such as <code>DateTime.Now</code> is not always equal to itself.</li>
<li>Properties may throw exceptions - fields will never do that.</li>
<li>Properties may have side effects or take a really long time to execute. Fields have no side effects and will always be as fast as can be expected for the given type. </li>
<li>Properties support different accessibility for getters/setters - fields do not (but fields can be made <code>readonly</code>)</li>
<li>When using reflection the properties and fields are treated as different <code>MemberTypes</code> so they are located differently (<code>GetFields</code> vs <code>GetProperties</code> for example)</li>
<li>The JIT Compiler may treat property access very differently compared to field access. It may however compile down to identical native code but the scope for difference is there.</li>
</ul>

blocks|key|3123981|text|访问器不仅仅是字段。其他人已经指出了几个重要的区别，我将再增加一个。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3123982|属性是接口类的一部分。例如：|3123983|interface+IPerson
{
++++string+FirstName+{+get;+set;+}
++++string+LastName+{+get;+set;+}
}|code-block|syntax|javascript|3123984|这个接口可以通过几种方式来满足。例如：|3123985|class+Person:+IPerson
{
++++private+string+_name;
++++public+string+FirstName
++++{
++++++++get
++++++++{
++++++++++++return+_name+??+string.Empty;
++++++++}
++++++++set
++++++++{
++++++++++++if+(value+==+null)
++++++++++++++++throw+new+System.ArgumentNullException("value");
++++++++++++_name+=+value;
++++++++}
++++}
++++...
}|3123986|在这个实现中，我们既保护了Person类不会进入无效状态，也保护了调用者不会从未分配的属性中得到null。|offset|length|style|CODE|3123987|但我们可以将设计推向更远。例如，接口可能不处理setter。可以说，IPerson接口的消费者只对获取属性感兴趣，而不是对设置属性感兴趣：|3123988|interface+IPerson
{
++++string+FirstName+{+get;+}
++++string+LastName+{+get;+}
}|3123989|以前的Person类实现就满足了这个接口。从消费者(消费IPerson)的角度来看，它还允许调用者设置属性这一事实是没有意义的。例如，构建器考虑具体实现的附加功能：|3123990|class+PersonBuilder:+IPersonBuilder
{
++++IPerson+BuildPerson(IContext+context)
++++{

++++++++Person+person+=+new+Person();

++++++++person.FirstName+=+context.GetFirstName();
++++++++person.LastName+=+context.GetLastName();

++++++++return+person;

++++}
}

...

void+Consumer(IPersonBuilder+builder,+IContext+context)
{
++++IPerson+person+=+builder.BuildPerson(context);
++++Console.WriteLine("{0}+{1}",+person.FirstName,+person.LastName);
}|3123991|在这段代码中，消费者不知道属性设置器--知道不关他的事。消费者只需要getter，他从接口，也就是从契约中获取getter。|3123992|IPerson的另一个完全有效的实现是一个不可变的person类和一个对应的person工厂：|3123993|class+Person:+IPerson
{
++++public+Person(string+firstName,+string+lastName)
++++{

++++++++if+(string.IsNullOrEmpty(firstName)+%7C%7C+string.IsNullOrEmpty(lastName))
++++++++++++throw+new+System.ArgumentException();

++++++++this.FirstName+=+firstName;
++++++++this.LastName+=+lastName;

++++}

++++public+string+FirstName+{+get;+private+set;+}

++++public+string+LastName+{+get;+private+set;+}

}

...

class+PersonFactory:+IPersonFactory
{
++++public+IPerson+CreatePerson(string+firstName,+string+lastName)
++++{
++++++++return+new+Person(firstName,+lastName);
++++}
}
...
void+Consumer(IPersonFactory+factory)
{
++++IPerson+person+=+factory.CreatePerson("John",+"Doe");
++++Console.WriteLine("{0}+{1}",+person.FirstName,+person.LastName);
}|3123994|在此代码示例中，使用者再一次不知道如何填充属性。使用者只处理getter和具体的实现(以及它背后的业务逻辑，比如测试名称是否为空)，留给专门的类-构建器和工厂。对于字段，所有这些操作都是完全不可能的。|3123995|entityMap^0|0|0|0|0|0|D|6|0|Y|7|0|0|3|6|S|7|0|0|0|0|7|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1C|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1D|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1E|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1F|8|@$O|1G|P|1H|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1I|8|@$O|1J|P|1K|Q|R]]|9|@]|A|$]]|$1|U|3|V|5|F|7|1L|8|@]|9|@]|A|$G|H]]|$1|W|3|X|5|6|7|1M|8|@$O|1N|P|1O|Q|R]|$O|1P|P|1Q|Q|R]]|9|@]|A|$]]|$1|Y|3|Z|5|F|7|1R|8|@]|9|@]|A|$G|H]]|$1|10|3|11|5|6|7|1S|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1T|8|@$O|1U|P|1V|Q|R]]|9|@]|A|$]]|$1|14|3|15|5|F|7|1W|8|@]|9|@]|A|$G|H]]|$1|16|3|17|5|6|7|1X|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|19|$]]

Accessors are more than fields. Others have already pointed out several important differences, and I'm going to add one more.

Properties take part in interface classes. For example:

<pre><code>interface IPerson
{
 string FirstName { get; set; }
 string LastName { get; set; }
}
</code></pre>

This interface can be satisfied in several ways. For example:

<pre><code>class Person: IPerson
{
 private string _name;
 public string FirstName
 {
 get
 {
 return _name ?? string.Empty;
 }
 set
 {
 if (value == null)
 throw new System.ArgumentNullException("value");
 _name = value;
 }
 }
 ...
}
</code></pre>

In this implementation we are protecting both the <code>Person</code> class from getting into an invalid state, as well as the caller from getting null out from the unassigned property.

But we could push the design even further. For example, interface might not deal with the setter. It is quite legitimate to say that consumers of <code>IPerson</code> interface are only interested in getting the property, not in setting it:

<pre><code>interface IPerson
{
 string FirstName { get; }
 string LastName { get; }
}
</code></pre>

Previous implementation of the <code>Person</code> class satisfies this interface. The fact that it lets the caller also set the properties is meaningless from the point of view of consumers (who consume <code>IPerson</code>). Additional functionality of the concrete implementation is taken into consideration by, for example, builder:

<pre><code>class PersonBuilder: IPersonBuilder
{
 IPerson BuildPerson(IContext context)
 {

 Person person = new Person();

 person.FirstName = context.GetFirstName();
 person.LastName = context.GetLastName();

 return person;

 }
}

...

void Consumer(IPersonBuilder builder, IContext context)
{
 IPerson person = builder.BuildPerson(context);
 Console.WriteLine("{0} {1}", person.FirstName, person.LastName);
}
</code></pre>

In this code, consumer doesn't know about property setters - it is not his business to know about it. Consumer only needs getters, and he gets getters from the interface, i.e. from the contract.

Another completely valid implementation of <code>IPerson</code> would be an immutable person class and a corresponding person factory:

<pre><code>class Person: IPerson
{
 public Person(string firstName, string lastName)
 {

 if (string.IsNullOrEmpty(firstName) || string.IsNullOrEmpty(lastName))
 throw new System.ArgumentException();

 this.FirstName = firstName;
 this.LastName = lastName;

 }

 public string FirstName { get; private set; }

 public string LastName { get; private set; }

}

...

class PersonFactory: IPersonFactory
{
 public IPerson CreatePerson(string firstName, string lastName)
 {
 return new Person(firstName, lastName);
 }
}
...
void Consumer(IPersonFactory factory)
{
 IPerson person = factory.CreatePerson("John", "Doe");
 Console.WriteLine("{0} {1}", person.FirstName, person.LastName);
}
</code></pre>

In this code sample consumer once again has no knowledge of filling the properties. Consumer only deals with getters and concrete implementation (and business logic behind it, like testing if name is empty) is left to the specialized classes - builders and factories. All these operations are utterly impossible with fields.

blocks|key|347035|text|字段和属性之间还有另一个重要的区别。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|347036|使用WPF时，只能绑定到公共属性。绑定到公共字段将不会工作。即使没有实现INotifyPropertyChanged+(尽管您总是应该实现)，这也是正确的。|offset|length|style|CODE|347037|entityMap^0|0|10|M|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

There is one other important difference between fields and properties.

When using WPF, you can only bind to public properties. Binding to a public field will not work. This is true even when not implementing <code>INotifyPropertyChanged</code> (even though you always should).

blocks|key|3124050|text|对于任何公共fields.This，您应该始终使用属性而不是字段，以确保您的库能够在未来需要时实现任何字段的封装，而不破坏现有的codes.If。您将现有库中的字段替换为属性，那么使用您的库的所有依赖模块也需要重新构建。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3124051|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You should always use properties instead of fields for any public fields.This ensures that your library
has the ability to implement encapsulation for any field if required in future without breaking the existing codes.If you replace the fields with properties in existing libraries then all the dependent modules using your library also need to be rebuilt.

blocks|key|345648|text|在其他答案和例子中，我认为这个例子在某些情况下是有用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|345649|例如，假设您有一个如下所示的OnChange+property：|offset|length|style|BOLD|CODE|345650|public+Action+OnChange+{+get;+set;+}|code-block|syntax|javascript|345651|如果你想使用委托，你需要将它的OnChange改为field，如下所示：|345652|public+event+Action+OnChange+=+delegate+{};|345653|在这种情况下，我们保护我们的字段免受不必要的访问或修改。|345654|entityMap^0|0|E|8|E|8|N|8|0|0|F|8|F|8|P|5|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]|$D|Z|E|10|F|H]|$D|11|E|12|F|H]]|9|@]|A|$]]|$1|I|3|J|5|K|7|13|8|@]|9|@]|A|$L|M]]|$1|N|3|O|5|6|7|14|8|@$D|15|E|16|F|G]|$D|17|E|18|F|H]|$D|19|E|1A|F|H]]|9|@]|A|$]]|$1|P|3|Q|5|K|7|1B|8|@]|9|@]|A|$L|M]]|$1|R|3|S|5|6|7|1C|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$]]

Among other answers and examples, I think this example is useful in some situations. 

For example let say you have a <code>OnChange</code> <code>property</code> like following:

<pre><code>public Action OnChange { get; set; }
</code></pre>

If you want to use delegates than you need to change it <code>OnChange</code> to <code>field</code> like this:

<pre><code>public event Action OnChange = delegate {};
</code></pre>

In such situation we protect our field from unwanted access or modification.

I realize that it seems to be a duplicate of <a href="https://stackoverflow.com/questions/295104/what-is-the-difference-between-a-field-and-a-property-in-c">What is the difference between a Field and a Property in C#?</a> but my question has a slight difference (from my point of view):

Once I know that

<ul>
<li>I will not use my class with "techniques that only works on properties" and </li>
<li>I will not use validation code in the getter/setter.</li>
</ul>

Is there any difference (except the style/future development ones), like some type of control in setting the property?

Is there any additional difference between:

<pre><code>public string MyString { get; set; }
</code></pre>

and 

<pre><code>public string myString;
</code></pre>

(I am aware that, that the first version requires C# 3.0 or above and that the compiler does create the private fields.)

Difference between Property and Field in C# 3.0+

编译器

我意识到它似乎是的复制品，但我的问题有一点不同(从我的角度来看)：一旦我知道这一点我不会将我的类与“仅对属性起作用的技术”一起使用，我也不会在with中使用验证代码是否有任何不同(除了样式/未来的开发)，就像在设置属性时的某种类型的控件？以下各项之间是否有其他区别：public string MyString { ge...

问C# 3.0+中属性和字段的区别
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C# 3.0+中属性和字段的区别EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C# 3.0+中属性和字段的区别
EN