ThreadPoolScheduler：默认/实例 [英] ThreadPoolScheduler: Default/Instance

问题描述

是否有理由在Rx 2.0 for WinRT中访问ThreadPoolScheduler的属性被命名为Default而在Rx 2.0 for Windows Phone上它被称为Instance？

创建多平台代码非常无聊。

---

客户端应用程序开发MVP

解决方案

我们使用了一种命名模式，如果该类型上没有公共构造函数，则使用 Instance ，从而显示只有一个实例可能。另一方面，WinRT的TaskPoolScheduler和ThreadPoolScheduler都有
构造函数，允许创建具有调整行为的实例。因此，静态属性仅提供常用的默认实例，因此名称为
默认。

回想起来，也许我们应该更加努力在v1.x设计中替换Instance for Default（如果只有一个实例，则它是默认的唯一竞争者）。事实上，我们已经在DispatcherScheduler上弃用了
Instance ，转而支持当前
（反映该实例基于System.Deployment。当前 .Dispatcher或为Thread获得的调度程序。当前线程），遵循这些命名准则，因为
实例名称不带任何名称有用的信息。

或者，您可以使用 Scheduler.Default ，它依赖于特定于平台的线程池功能并位于可移植层中。

Hi,

Is there is reason why in Rx 2.0 for WinRT the property to access the ThreadPoolScheduler is named Default while on Rx 2.0 for Windows Phone it's called Instance?

It makes it quite boring to create multiplaform code.

---

Client Application Development MVP

解决方案

We used a naming pattern where Instance is used if there's no public constructor on the type, revealing there's one and only one instance possible, ever. On the other hand, the TaskPoolScheduler and ThreadPoolScheduler for WinRT both have constructors that allow to create instances with tweaked behavior. As such, the static property only provides a commonly used default instance, hence the name Default.

In retrospect, maybe we should have pushed harder to substitute Instance for Default in the v1.x design (if there's only one instance, it's the only contender for a default). In fact, we've deprecated Instance on DispatcherScheduler in favor of Current (reflecting the instance is based on System.Deployment.Current.Dispatcher or the dispatcher obtained for Thread.CurrentThread), to follow those naming guidelines because the Instance name doesn't carry any useful information.

Alternatively, you could use Scheduler.Default, which relies on the platform-specific thread pool capabilities and sits in the portable layer.

这篇关于ThreadPoolScheduler：默认/实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！