RX中是否存在只读的BehaviorSubject接口,如果不存在,那么制作一个接口是不是一个坏主意？

Question

RX的实现提供BehaviorSubject<T>和Variable<T>作为随时间变化的建模特性机制(C#INotifyPropertyChanged的一种有用的替代品).

通常这些都是暴露的,Observable<T>但是将属性公开为更有用:

class ObservableValue<T> : Observable<T>{
  var currentValue:T { get }
}

这可以在swift中沿着这些行创建:

class ObservableValue<Element> : ObservableType {

  typealias E = Element

  private let subject:BehaviorSubject<E>

  var currentValue:E {
      get {
          return try! subject.value()
      }
  }

  init(subject:BehaviorSubject<E>) {
      self.subject = subject
  }

  func subscribe<O: ObserverType where O.E == E>(observer: O) -> Disposable {
      return self.subject.subscribe(observer)
  }

}

这已经存在了吗？如果不是因为它违背了Rx的目标？

围绕它的唯一方法是公开一个单独的currentValue或写消费者,假设暴露的Observable背后的具体实现是BehaviourSubject或链中的某个地方发生了重放(),例如以下代码片段并未明确表示当我订阅时,我会得到一个值:

class MyViewModel {
  // 'I will notify you of changes perhaps including my current value'
  myProperty:Observable<String> 
}

所以代码必须被编写为好像它的"异步",它具有基本的假设,它将以几乎同步的方式运行,而不是:

class MyViewModel {
  // 'I have a current value and will notify you of changes going forward'
  myProperty:ObservableValue<String> 
}

Answer 1

经过深思熟虑并对其进行了更深入的讨论，大概它不存在（也许不应该存在）的原因是它引入了命令式访问状态。

其他维护状态的机制（例如scan）在链接的 observables 范围内这样做，而不是作为“死胡同”直接调用，例如“立即给我值”。

也许它会在混合反应式/命令式方法中占有一席之地，但它可能只会阻碍反应式风格的完全接受。

这类似于在一半代码中使用承诺或任务，然后在其他部分恢复到同步阻塞代码。