R3项目中Observable基类使用注意事项

理解R3中的Observable基类

在R3(Reactive Runtime)项目中，Observable<T>是一个用于创建可观察序列的基类。开发者可以通过继承这个基类来实现自定义的可观察序列。然而，在使用过程中需要注意一些关键的设计原则和潜在陷阱。

问题现象分析

开发者在使用Observable<T>作为基类时，可能会遇到System.InvalidOperationException: Disposable is already assigned异常。这种情况通常发生在以下场景：

1. 开发者创建了一个继承自Observable<T>的类
2. 在SubscribeCore方法中，尝试通过另一个Subject来转发订阅
3. 直接返回Subject的订阅结果时会出现异常

问题根源

异常的根本原因在于SubscribeCore方法的实现方式。当开发者尝试在方法内部先获取Subject的订阅，然后再返回这个订阅时，实际上发生了对同一个SingleAssignmentDisposableCore的两次赋值操作：

protected override IDisposable SubscribeCore(Observer<T> observer)
{
    var subscription = _subject.Subscribe(observer); // 第一次赋值
    return subscription; // 返回时发生第二次赋值
}

解决方案

推荐解决方案

正确的做法是避免在SubscribeCore方法中直接转发订阅。R3的设计初衷是让Observable<T>作为可观察序列的基类，而不是作为转发代理。如果需要转发功能，应该使用AsObservable()等方法。

临时解决方案

如果确实需要在自定义Observable中包装另一个Subject，可以使用以下方式绕过问题：

protected override IDisposable SubscribeCore(Observer<T> observer)
{
    return ObservableSubscribeExtensions.Subscribe(_subject, observer.OnNext);
}

这种方式避免了直接返回Subject的订阅结果，从而防止了双重赋值的问题。

设计原则与最佳实践

1. 单一职责原则：Observable<T>应该作为可观察序列的实现基类，而不是转发代理
2. 避免继承滥用：不是所有需要实现IObservable<T>的场景都适合继承Observable<T>
3. 使用组合而非继承：当需要包装现有Observable时，优先考虑组合模式
4. 遵循框架设计意图：理解并遵循R3框架的设计理念，避免反模式使用

总结

在R3项目中使用Observable<T>基类时，开发者需要理解其设计意图和适用场景。当遇到"Disposable is already assigned"异常时，应该重新审视代码设计是否符合框架的设计原则。在大多数情况下，使用组合而非继承，或者利用框架提供的转换方法（如AsObservable()）会是更好的选择。