您有一个面向拉动的 Observable/Listenable,它会在某些状态发生变化时通知观察者/监听者。
状态由多个数据块组成,您的一些观察者/侦听器并不关心整个状态。
你通常更喜欢通知所有的观察者/监听者,并允许他们在他们关心的任何事情没有改变时忽略通知吗?
或者您通常更喜欢为每个“块”数据使用单独的 Observable,以便保证您的观察者/侦听器只获得他们需要响应的通知?
这取决于情况吗?
您对 Observables/Listenables 的粒度有什么一般的想法吗?
您有一个面向拉动的 Observable/Listenable,它会在某些状态发生变化时通知观察者/监听者。
状态由多个数据块组成,您的一些观察者/侦听器并不关心整个状态。
你通常更喜欢通知所有的观察者/监听者,并允许他们在他们关心的任何事情没有改变时忽略通知吗?
或者您通常更喜欢为每个“块”数据使用单独的 Observable,以便保证您的观察者/侦听器只获得他们需要响应的通知?
这取决于情况吗?
您对 Observables/Listenables 的粒度有什么一般的想法吗?
您正在权衡维护成本与交付成本。如果你有细粒度的事件定义,每个观察者只得到他需要的东西,所以你不需要支付交付给不感兴趣的观察者的开销——但是因为每一种新的金块都需要添加到某种方式的系统。
在交付成本相对较高(通过网络传输的消息)的 Pub/Sub 消息传递系统中,通常需要特别注意主题定义。精心设计的主题层次结构通常很有用。所以我们得到像
sport
football
england
premier
champioship
scotland
spl
france
...
cricket
australia
...
india
sri lanka
因此允许在各个级别订阅。您可以订阅所有运动或(如某些人可能)一直到
sport/football/england/championship/watford
作为一般的经验法则,专门的接口利大于弊,所以我肯定会实现更多而不是更少。
不过,这显然确实引起了这种情况。仅在必要时才专门从事这种方式,从您的情况来看似乎是这样,否则就像通知谷物制造商小麦需要收割一样。它根本不适用。
这不仅仅是维护。Observables 和 Observers 之间的接口越具体,它们就越耦合。
《四人组》一书中有一个专门针对这个问题的部分,他们建议不要同时使用推式和拉式模型。拉模型可能效率低下,推模型可能没有足够的可重用性。
因此,这在很大程度上取决于情况。我倾向于略高于拉模型。
如果我必须这样做,我可能会创建一个 Observable 类,该类将为每种类型的 nugget 设置一个事件,并为任何 nugget 设置一个全局事件。有点像中路。