假设我有 A 类。在 A 类中,有一组事件反映了内部的任何变化——集合的变化、基本属性/状态的变化。并且该对象有一个属性——B 类对象,它应该监视这些状态并在分析所有更改的集合后执行一些工作。
在创建 B 类对象时,将对 A 类对象的引用传递给其构造函数并绑定到事件是合乎逻辑的。
有兴趣有任何其他方式、实现或模式。
假设我有 A 类。在 A 类中,有一组事件反映了内部的任何变化——集合的变化、基本属性/状态的变化。并且该对象有一个属性——B 类对象,它应该监视这些状态并在分析所有更改的集合后执行一些工作。
在创建 B 类对象时,将对 A 类对象的引用传递给其构造函数并绑定到事件是合乎逻辑的。
有兴趣有任何其他方式、实现或模式。
在 C# 中,“观察者”模式可以通过多种方式实现,例如:
IObserver/IObservable基于委托
基于委托的解决方案是一个经典的回调。这种方法的优点是没有显式的、类型化的事件处理程序(事件提供者和消费者之间的关系不受任何监管)和方法的简单性——当事件发生时,类方法
Consumer调用委托参数:当事件发生时,将调用委托
act及其整个调用列表,从而保持事件处理的多样性。基于事件
该方法与前一种方法相似,但不同之处在于它允许您为任意数量的处理程序订阅事件(无需像前一种方法那样建模 1:1 关系)或根本没有处理程序。
该方法与前一种方法类似,但不保证至少存在一个处理程序。
使用强类型接口
在这种方法中,消费者使用特定的处理程序接口来处理提供者的事件,严格形式化了提供者和消费者之间的关系。
这几乎是 C# 中订阅者模式的经典实现(以及 Objective-C 中的委托模式,唯一的区别是必须严格定义所有处理程序)。
实施此方法需要密切监视 SRP 违规和提供程序事件一致性。
使用特殊的 IObserver/IObservable 接口
从 .NET 4 开始,可以使用特殊接口
IObserver/IObservable来实现事件序列的观察者模式:在“观察者”模式的“经典”版本中,被观察对象具有方法:
并且有些观察者实现了一些
IНаблюдатель包含该方法的接口Обновление()。每个观察者都包含对被观察主题的引用,并自行管理订阅/取消订阅,或在方法参数中接收引用
Обновление()。在我看来,第二个选项更可取,因为第一个“闻起来”有几个职责,尽管可能有这些选项的组合 - 例如,观察者包含指向被观察主题的链接,但不控制订阅,一般来说这个链接是公开的,可以从外部替换。
至于C#:
在C#中有一个事件机制,其实就是这个模式的实现,所以observable对象不需要具体实现什么,只需要设置事件可订阅,必要时调用即可。