Scala 集合转发器和代理的用例

发布于 2024-11-02 10:55:59 字数 1312 浏览 4 评论 0原文

Scala 的集合库包含转发器 IterableForwarder, TraversableForwarderSeqForwarder 和代理,例如 IterableProxyMapProxySeqProxySetProxyTraversableProxy 等。转发器和代理都将集合方法委托给底层集合对象。这两者之间的主要区别在于转发器不会转发会创建同类新集合对象的调用。

在什么情况下我会更喜欢其中一种类型而不是另一种?转发器为何以及何时有用?如果它们有用,为什么没有 MapForwarderSetForwarder

我认为如果想要使用附加方法为集合构建包装器或为标准集合提供便利,最常使用代理。

Scala's collection library contains the forwarders IterableForwarder, TraversableForwarder, SeqForwarder and proxies like IterableProxy, MapProxy, SeqProxy, SetProxy, TraversableProxy, etc. Forwarders and proxies both delegate collection methods to an underlying collection object. The main difference between these two are that forwarders don't forward calls that would create new collection objects of the same kind.

In which cases would I prefer one of these types over the other? Why and when are forwarders useful? And if they are useful why are there no MapForwarder and SetForwarder?

I assume proxies are most often used if one wants to build a wrapper for a collection with additional methods or to pimp the standard collections.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

命硬 2024-11-09 10:55:59

我认为这个答案提供了一些关于一般来说,代理(并且您对包装器和拉皮条的假设是正确的)。

据我所知,Proxy 的子类型更针对最终用户。使用Proxy时,代理对象和self对象在所有意图和目的上都将相等。我认为这实际上是主要的区别。如果该假设不成立,请不要使用Proxy

Forwarder 特性似乎仅用于支持 ListBuffer,如果需要推出自己的基于 CanBuildFrom< 之上构建的集合类,则可能更合适/code> 基础设施。所以我想说它更适合图书馆编写者,该图书馆基于 2.8 集合设计。

I think this answer provides some context about Proxy in general (and your assumption about wrapper and pimping would be correct).

As far as I can tell the subtypes of Proxy are more targeted to end users. When using Proxy the proxy object and the self object will be equal for all intent and purposes. I think that's actually the main difference. Don't use Proxy if that assumption does not hold.

The Forwarder traits only seems to be used to support ListBuffer and may be more appropriate if one needs to roll out their own collection class built on top of the CanBuildFrom infrastructure. So I would say it's more targeted to library writers where the library is based on the 2.8 collection design.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文