【发布时间】:2011-10-03 18:12:27
【问题描述】:
public class Foo
{
private readonly Bar _bar;
}
public class Foo2
{
private Bar _bar;
}
我认为将其标记为只读没有任何好处。它是私有的,如果我尝试在内部做一些事情来修改它,那是我很愚蠢,因为我知道我希望我的班级如何表现?那么,有什么意义呢?我认为这里没有任何性能提升,所以不可能。
【问题讨论】:
public class Foo
{
private readonly Bar _bar;
}
public class Foo2
{
private Bar _bar;
}
我认为将其标记为只读没有任何好处。它是私有的,如果我尝试在内部做一些事情来修改它,那是我很愚蠢,因为我知道我希望我的班级如何表现?那么,有什么意义呢?我认为这里没有任何性能提升,所以不可能。
【问题讨论】:
让编译器防止你变笨总是好的。
让编译器防止其他人变得愚蠢尤其好,即使他们不熟悉代码库。
它还可以告诉其他阅读您的代码的人该字段永远不会改变
【讨论】:
如果您想在实例化时分配它,但不希望它是可更改的,Readonly 很好。我能想到的一个很好的场景可能是一个带有用户名/密码的数据库类。
public MyClass(string user, string password){
this.username = username;
this.password = password;
this.connect();
}
假设在对象处于活动状态的整个期间都保持连接,存储此信息以供参考可能是有意义的,但一旦建立连接就可以防止将来发生更改。
【讨论】:
在你编写这个类的时候,你知道你希望它如何表现。
但是:
您的声明允许编译器验证您的意图是否得到满足,成本低廉且重复。它会向您和其他人传达您的意图。
【讨论】:
你是对的,没有性能提升。但是,这里有一些关键的区别:
如果您打算创建一个不尝试修改 _bar 的类,它实际上应该是一个只读字段。我可以在这里看到两件事:
现在,如果您打算将其保持为空,则它应该 NOT 是只读的,直到调用另一个方法来初始化它。但是,为此我会查看Lazy<T>。
基本上,这是您的决定。如果您真的要成为修改此类的唯一 人,我仍然会说遵循这些规则。这是做到这一点的最佳实践方式。 :)
【讨论】:
它是私有的,如果我尝试在内部做一些事情来修改它,那我就是愚蠢,因为我知道我希望我的班级表现如何?
如果您是项目历史上唯一一个会查看或修改源代码的人并且您有完美的记忆,那么,是的。不需要 cmets 或其他编程约定。就当牛仔吧。
否则,使用约定来(重新)执行意图不是一个坏主意。
【讨论】:
假设一个类应该包含一组可变的T,并且它有一个私有字段T[] theArray。可以通过多种方式设置该类:
这三种不同的方法对线程安全等事物具有不同的含义。如果将 readref-copy-modify-writeref 序列放置在 Interlocked.CompareExchange 循环中,则第一个可以成为线程安全的。通过使单个元素写入线程安全,可以使最后一个线程安全。然而,第二个只能通过至少让所有写操作共享一个对整个列表来说是通用的锁并要求读者仔细检查他们的操作以确保一致性,或者要求所有读写访问都必须通过一个公共锁。
【讨论】: