这种 .Net 模式有什么好处
我一直在寻找一种模式，能够提供同一类的线程安全和不安全版本。这在技术方面是非常明显的。我想是希望找到命名/访问约定等...
所以我在“Systems.Collections”命名空间中到处都发现了这种模式：
public class WhatEv
{
private class SyncWhatEv : WhatEv
{
// overrides IsSyncronized = true
// overrides whatever else to make it thread safe
}
public virtual bool IsSynchronized
{
get { return false; }
}
public static WhatEv Synchronized(WhatEv whatEv)
{
return new SyncWhatEv(whatEv);
}
}
有许多类实现了这一点：HashTable、Queue、ArrayList、Stack 等。我明白了继承。但为什么要让它成为一个私有的嵌套类并让用户费尽心思才能到达它呢？这样做有什么好处吗？
I was looking for a pattern to be able to provide both a thread-safe and unsafe version of the same class. The technical aspects of this are pretty obvious. I guess was hoping to find naming/access conventions etc...
So I find this pattern everywhere in the 'Systems.Collections' namespace:
public class WhatEv
{
private class SyncWhatEv : WhatEv
{
// overrides IsSyncronized = true
// overrides whatever else to make it thread safe
}
public virtual bool IsSynchronized
{
get { return false; }
}
public static WhatEv Synchronized(WhatEv whatEv)
{
return new SyncWhatEv(whatEv);
}
}
There are a number of classes that implement this: HashTable, Queue, ArrayList, Stack, etc... I understand the inheritance. But why make it a private, nested class and make the user jump through a hoop to get to it? Are there any benefits to doing it this way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在大多数情况下，不需要对象的线程安全版本（即Hashtable、Queue）。因此，添加默认情况下线程安全所需的开销是没有意义的。使用 Synchronized 方法，允许需要线程安全的用户获得线程安全版本。
除了线程安全之外，该对象的同步版本不添加任何附加功能。它们不会暴露任何新成员，了解它们的底层类型也没有真正的帮助。因此，它们被设为私有，并且“看起来”就像它们的公共/基类。
In most cases, a thread-safe version of the object (i.e. Hashtable, Queue) is not needed. Therefore, it doesn't make sense to add the overhead needed to make it thread-safe by default. Using the Synchronized method, allows users that need thread-safety to get a thread-safe version.
The synchronized version of the object doesn't add any additional functionality, other than thread-safety. They don't expose any new members, nor does knowing their underlying type really help. So they are made private and simply "look" like their public/base class.
理论上，这是一个好主意，@CodeNaked 有很好的解释。在实践中，这仍然存在问题。例如，如果您需要对线程安全类进行两次调用，并且需要对这两个调用组合进行线程安全，则仍然需要执行锁定。这个SO项目中有很好的解释：在 C# 中，使用 Queue.Synchronized 还是 lock() 来保证线程安全更好？
In theory, this is a good idea, and @CodeNaked has a good explanation. In practice, there are still problems with this. For example, if you need to make 2 calls into your thread-safe class and need thread safety for both calls combined, you still need to do a lock. Good explanation in this SO item: In C# would it be better to use Queue.Synchronized or lock() for thread safety?
经过周末的思考，但没有得到进一步的答复。我决定答案是：你们都疯了。提供对象的同步版本的全部目的是为了线程安全，但线程在编译时无法要求对象的线程安全版本。该对象的验证必须在运行时进行，这是......假的。
感谢大家的意见。我很感激。
After pondering this for the weekend, and after getting no further responses. I've decided the answer is: MS be crazy y'all. The whole point of offering a synchronize version of the object is for thread safety, yet a thread has no way at compile time to require a thread safe version of the object. The validation of this object has to take place at runtime, which is... bogus.
Thanks to everyone for their input. I appreciate it.