为什么要避免在C#中使用属性? [英] Why should I avoid using Properties in C#?

查看:42
本文介绍了为什么要避免在C#中使用属性?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

杰弗里·里希特(Jeffrey Richter)在他的出色著作《 CLR Via C#》中说,他不喜欢属性,建议不要使用它们.他给出了一些理由,但我不太了解.谁能向我解释为什么或不应该使用属性?在具有自动属性的C#3.0中,这会更改吗?

In his excellent book, CLR Via C#, Jeffrey Richter said that he doesn't like properties, and recommends not to use them. He gave some reason, but I don't really understand. Can anyone explain to me why I should or should not use properties? In C# 3.0, with automatic properties, does this change?

作为参考,我添加了Jeffrey Richter的意见:

•属性可以是只读的也可以是只写的;字段访问始终是可读写的.如果定义属性,则最好同时提供get和set访问器方法.

• A property may be read-only or write-only; field access is always readable and writable. If you define a property, it is best to offer both get and set accessor methods.

•属性方法可能会引发异常;字段访问永远不会引发异常.

• A property method may throw an exception; field access never throws an exception.

•无法将属性作为out或ref参数传递给方法;不能将其作为参数传递给方法.田野可以.为了例如,以下代码将无法编译:

• A property cannot be passed as an out or ref parameter to a method; a field can. For example, the following code will not compile:

using System;
public sealed class SomeType
{
   private static String Name 
   {
     get { return null; }
     set {}
   }
   static void MethodWithOutParam(out String n) { n = null; }
   public static void Main()
   {
      // For the line of code below, the C# compiler emits the following:
      // error CS0206: A property or indexer may not
      // be passed as an out or ref parameter
      MethodWithOutParam(out Name);
   }
}

•属性方法可能需要很长时间才能执行;现场访问总是立即完成.使用属性的常见原因是执行线程同步,即可以永远停止线程,因此,如果线程同步,则不应使用属性是必须的.在这种情况下,首选方法.另外,如果您的班级可以远程访问(例如,您的类派生自System.MashalByRefObject),调用属性方法将非常慢,因此,方法优于财产.我认为,从MarshalByRefObject派生的类永远不要使用属性.

• A property method can take a long time to execute; field access always completes immediately. A common reason to use properties is to perform thread synchronization, which can stop the thread forever, and therefore, a property should not be used if thread synchronization is required. In that situation, a method is preferred. Also, if your class can be accessed remotely (for example, your class is derived from System.MashalByRefObject), calling the property method will be very slow, and therefore, a method is preferred to a property. In my opinion, classes derived from MarshalByRefObject should never use properties.

•如果连续多次调用,则属性方法可能会各自返回不同的值时间;字段每次都返回相同的值.System.DateTime类具有只读现在的属性,返回当前日期和时间.每次您查询此属性,它将返回不同的值.这是一个错误,Microsoft希望他们可以通过将Now作为方法而不是属性来修复该类.

• If called multiple times in a row, a property method may return a different value each time; a field returns the same value each time. The System.DateTime class has a readonly Now property that returns the current date and time. Each time you query this property, it will return a different value. This is a mistake, and Microsoft wishes that they could fix the class by making Now a method instead of a property.

•属性方法可能会导致明显的副作用;现场访问从未如此.其他换句话说,类型的用户应该能够在任何情况下设置由类型定义的各种属性他或她选择的顺序而没有注意到类型中的任何不同行为.

• A property method may cause observable side effects; field access never does. In other words, a user of a type should be able to set various properties defined by a type in any order he or she chooses without noticing any different behavior in the type.

•属性方法可能需要额外的内存或返回对某些内容的引用这实际上不是对象状态的一部分,因此修改返回的对象没有任何作用对原始物体的影响;查询一个字段总是返回对一个对象的引用保证是原始对象状态的一部分.使用具有以下特征的财产返回副本可能会使开发人员非常困惑,而且此特征经常出现没有记录.

• A property method may require additional memory or return a reference to something that is not actually part of the object's state, so modifying the returned object has no effect on the original object; querying a field always returns a reference to an object that is guaranteed to be part of the original object's state. Working with a property that returns a copy can be very confusing to developers, and this characteristic is frequently not documented.

推荐答案

Jeff不喜欢属性的原因是因为它们看起来像字段-因此,不了解差异的开发人员将把它们当作字段一样对待,并假设它们执行起来会很便宜等等.

Jeff's reason for disliking properties is because they look like fields - so developers who don't understand the difference will treat them as if they're fields, assuming that they'll be cheap to execute etc.

我个人在这一点上与他不同意-我发现属性使客户端代码比等效的方法调用更易于阅读.我同意开发人员需要知道属性基本上是伪装的方法-但我认为教育开发人员比使方法更难于阅读代码要好.(特别是,在看到在同一条语句中调用了多个getter和setter的Java代码之后,我知道等效的C#代码将更容易阅读.理论上,Demeter定律非常好,但有时 foo.Name.Length 确实是使用的正确方法...)

Personally I disagree with him on this particular point - I find properties make the client code much simpler to read than the equivalent method calls. I agree that developers need to know that properties are basically methods in disguise - but I think that educating developers about that is better than making code harder to read using methods. (In particular, having seen Java code with several getters and setters being called in the same statement, I know that the equivalent C# code would be a lot simpler to read. The Law of Demeter is all very well in theory, but sometimes foo.Name.Length really is the right thing to use...)

(而且,不,自动实现的属性并不能真正改变其中的任何一个.)

(And no, automatically implemented properties don't really change any of this.)

这有点像反对使用扩展方法的论点-我可以理解其原因,但在我看来,实际好处(谨慎使用时)超过了缺点.

This is slightly like the arguments against using extension methods - I can understand the reasoning, but the practical benefit (when used sparingly) outweighs the downside in my view.

这篇关于为什么要避免在C#中使用属性?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆