使用自动实现的属性超过手动实现的属性的任何原因？

我明白PROPERTIES超过FIELDS的优点，但我觉得使用AUTO实现的属性而不是MANUAL实现的属性并没有真正提供任何优势，除了使代码更简洁一些以外。使用自动实现的属性超过手动实现的属性的任何原因？

我感觉舒服多用：

private string _postalCode; 

    public string PostalCode 
    { 
     get { return _postalCode; } 
     set { _postalCode = value; } 
    }

相反的：

public string PostalCode { get; set; }

主要是因为如果我想要做的任何种类的获取和设置的自定义实现的，我要创建无论如何由私人领域支持我自己的财产。那么为什么不从一开始就咬住子弹，并立即给予所有属性这种灵活性，以保持一致性？考虑到您在Visual Studio中所做的所有操作都是单击您的专用字段名称，然后按Ctrl + E，即可完成，但这并不需要额外的时间。如果我手动执行，那么最终会出现不一致性，其中有一些由专用字段支持的手动创建的公共属性，以及一些自动实现的属性。无论是全自动还是全部手动，我都感觉好多了。

这是我吗？我错过了什么吗？我误解了什么吗？我是否过分强调一致性？我总是可以找到关于C＃特性的合法讨论，几乎总是有优点和缺点，但在这种情况下，我确实找不到任何推荐使用自动实现属性的人。

来源

2011-11-14 CptSupermrkt

你说你现在可以这样做 - 因为将来你可能必须这样做。为什么浪费时间做一些容易出错的东西（你可能最终会复制和粘贴），只有在需要时才能做到这一点？ – Rob

感谢罗布。我的推理是，使用Visual Studio，只需一次额外的按键即可创建手动实现的属性，因此不会复制/粘贴。如果有一天我确实需要创建自己的实现，那么我不会在自动实现的属性和手动实现的属性之间产生分歧，它是100％或100％。通过从一开始就充分利用手册，我可以随时创建自己的实现，而无需自动实现某些属性，并且某些属性是手动的。当然，我明白你的观点。 – CptSupermrkt

在这种情况下，我和你一起坚持100％的手动执行。在VS 2010（至少）中遇到手动获取/设置器 – Rob

除简洁之外，它不会给你任何额外的东西。如果你更喜欢更详细的语法，那么一定要使用它。

使用自动道具的一个好处是，它可以使您避免犯一个愚蠢的编码错误，例如意外地将错误的私有变量分配给属性。相信我，我已经做到了！

你对汽车道具不太灵活的观点是不错的。您拥有的唯一灵活性是通过使用private get或private set来限制范围。如果你的吸气者或安装者对他们有任何复杂性，那么汽车道具不再是一个可行的选择。

来源

2011-11-14 03:24:57

非常感谢，这几乎清除了它。 – CptSupermrkt

根据我的经验，公共属性让人们摆脱了面向对象的思维。我现在所做的一个项目有一些对象，只有一些属性初始化了一些属性，所以如果该属性为null或者不是，并且代码库中有很多区域检查null。我认为它们对于某些情况非常有用，如果我强调它们似乎是魔鬼。 – CodyEngel

@CodyEngel不保证通过访问者访问的对象也不是null。如果人们会用属性编写潦草的代码，他们会不编写潦草的代码。 – iheanyi

有人think that automatic properties can be somewhat evil但除此之外他们只是语法糖。除了保存几行代码之外，使用它们并不会带来任何好处，您可以为自己创建更多的工作（因为您希望执行一些检查或引发事件，因此必须手动实现它）。一致性在编程（imho）中非常有用。

来源

2011-11-14 03:28:53 ChrisWue

啊，所以有关于这个地方的讨论:)谢谢你的链接！ – CptSupermrkt

我不知道别人，但我倾向于暂停时间去思考我应该的名字我变量和功能，以便其他人可以理解我的代码。

所以，当我使用汽车 -implemented性质，我只有一次暂停。

当我需要支持字段我需要停下来两次，所以它会减慢发展有点:)

我做到这一点的方法是：

使它成为一个私有变量在开始时
如果需要，请将其更改为公开自动实施。
如果我需要获取或设置一些代码，请将其更改为后台字段。

如果一个类的不同属性暴露不同，没有任何错误。

来源

2011-11-14 03:32:09

您将失去控制权的事情之一是能够将后台字段指定为NonSerialized，但在此情况下为属性创建后台字段很容易。

忘记：如果您或您使用的任何产品在成员（即WCF）上执行反射，那么您将看到损坏的支持字段名称，而不是您创建的“漂亮”支持字段。

如果您之前提供了对服务的访问权限，或者如果您在接收端反序列化为相同的类结构（即在WCF管道的两端使用相同的类），这可能非常重要。在这种情况下，您不一定能够反序列化，因为您可以保证支持字段名称是相同的，除非您共享相同的DLL而不是源代码。

再澄清一点：假设您有一个Web服务，通过WCF将您的一些业务对象公开给您创建的Silverlight客户端。为了重用您的业务逻辑，您的Silverlight客户端会添加对业务对象源代码的引用。如果您有自动实现的属性，则无法控制后备字段名称。由于WCF序列化成员而不是属性，因此无法确定从WCF服务传输到Silverlight的对象是否会正确反序列化，因为支持字段名称几乎肯定会不匹配。

来源

2011-11-14 04:00:20

自动实现的属性不保证在构建之间保持相同的后台字段名称。因此，理论上可能会在一个版本的程序集中序列化一个对象，然后在另一个程序集中重新序列化同一对象可能会导致重大更改。

这是高度不太可能，但如果您试图保持为新版本“换出”您的程序集版本的能力，这是一个有效的担忧。

通过使用手动实现的属性，可以保证后台字段永不改变（除非您专门更改它）。

除了那个微小的差异，自动属性是一个正常的属性，是自动实现的后台字段。

来源

2011-11-14 04:14:34

我看到使用自动属性的优势之一是;在调试应用程序时，它不会进入不必要的获取/设置部分。我知道我们可以使用Debugger Attributes或Step over来避免相同的情况;但是，如果在大型应用程序上进行调试，则会发生大多数情况。

来源

2011-11-14 05:11:54 Riju

使用自动实现的属性超过手动实现的属性的任何原因？

回答

相关问题