观测者商业模式，又称为正式发布订户商业模式，是一类犯罪行为设计商业模式——你能表述一类订户监督机制，可在第一类该事件出现时通告数个检视该第一类的其它第一类。
观测者商业模式表述了一类两对多的倚赖亲密关系，让数个观测者第一类与此同时窃听某三个主轴第一类。那个主轴第一类在状况上出现变化时，会通告大部份观测者第一类，让它能离线他们。
从表述中，无从辨认出，观测者与 被观测者/ 公共信息是那个商业模式中最重要的共同组成原素。
QQ的社会公众号能被视作日常生活中最众所周知的观测者商业模式的范例。假如你订户了Flutter街道社区，每每 Flutter 街道社区正式发布该文时，就会给你或其它订户者发送那个最新消息，这当中你是观测者，社会公众号Flutter街道社区是被观测者(Observable)或发布者(Subject)。
events)，而观测者相等于该事件接收机(sinks of events)。
与此同时，观测者商业模式也是同时实现积极响应式程式设计的此基础，RxDart、EventBus 等库都是观测者商业模式下的乙醛。
面向第一类
面向第一类中，观察者和和公共信息(被观测者)依次相关联三个类(Observer 和 Subject)的第一类。
正式发布类(Subject)中一般来说会有提供更多给每一第一类订户或中止订户公共信息该事件流的订户监督机制，主要包括：
三个用作储存订户者对象提及的条目核心成员表达式；三个用作加进或删掉该条目中订户者的私有方式。
//被观测者class Subject { List observers; Subject([List observers]){ observers = observers ??[];} //注册登记观测者 void registerObserver(Observer observer){ observers.add(observer);} //解注册登记观测者 void unregisterObserver(Observer observer){ observers.remove(observer)} //通告观测者 void notifyobservers(Notification notification){ for (var observer in observers){ observer.notify(notification);} }}
这时，每每该事件出现，它只需结点订户者并初始化其第一类的某一通告方式方可(如下面代码中的 notifyobservers 方式)。
实际应用中，三个公共信息一般来说会相关联数个订户者，且公共信息与订户者应当遵循面向第一类的开发设计原则，因此：
为了避免耦合，订户者们必须同时实现同样的接口；公共信息仅通过该接口与订户者交互，接口方式能声明参数，这样公共信息在发出通告时就能传递一些上下文数据(如下面代码中的 notification 第一类)。
//观测者class Observer { String name; Observer(this.name); void notify(Notification notification){ print(“[${notification.timestamp.toIso8601String()}] Hey $name,${notification.message}!”);}}
这样，我们能得出如下这样用 Dart 语言同时实现的观测者商业模式了，下面是三个简单的应用：
//具体的被观测者 CoffeeMaker//每每 Coffee 制作完成发出通告给观测者。class CoffeeMaker extends Subject { CoffeeMaker([List observers]): super(observers); void brew(){ print(“Brewing the coffee…”); notifyobservers(Notification.forNow(“coffees done”));}}void main(){ var me = Observer(“Tyler”); var mrCoffee = CoffeeMaker(List.from([me])); var myWife = Observer(“Kate”); mrCoffee.registerObserver(myWife); mrCoffee.brew();}
这里的 CoffeeMaker 继承自 Subject，作为三个具体的正式发布类，brew()方式是其内部，每每咖啡制作完成后，用作通告其它各个观测者的方式。下面代码中，我们在 mrCoffee 这台咖啡机上注册登记了 myWife 这三个观测者，mrCoffee.brew();触发后，myWife 内部的 notify 方式就会被初始化。
观测者商业模式很好的同时实现了他们两者之间正式发布订户的亲密关系，在实际应用中，被观测者正在处理的该事件很可能是异步的，而作为观测者不必显示的去阻塞等待该事件的完成，而是由被观测者通告，当该事件完成后，再将该事件主动地推给关心那个该事件的观测者。与之相对的，有一类观测者也会使用后台线程时刻轮询地窃听着其关心的主轴该事件，那个话题我们暂不展开。
观测者商业模式使用不慎的话，也很容易出现传说中的失效窃听器问题，导致内存泄漏，因为在基本同时实现中，被观测者依然持有观测者的强提及，假如该事件中途，被观测者已经不存在时或不再关心此该事件，就会导致观测者无法被回收，因此，我们在这种情况下应当在被检视中做好中止订户的监督机制，及时释放无用的资源。
Dart
Stream 能被看作是 Dart 语言原生支持的观测者商业模式的众所周知模型之一，它本身是 Dart:async 包中三个用作异步操作的类，积极响应式程式设计库 RxDart 也是基于 Stream 封装而成的。
从概念上讲，我们能将 Stream 看做是三个能连接两端的传送带，作为开发者，我们能在传送带的一端放入数据，Stream 就会将这些数据传送到另一端。
和现实中的情况类似，假如传送带的另一端没有人接受数据，这些数据就会被程序丢弃，因此，我们一般来说会在传送到尾端安排三个接收数据的第一类，在积极响应式程式设计中，它被称为数据的观测者。
假如说上文 Dart 面向第一类中，观测者和被观测者两者的亲密关系是在尽量保持低耦合的情况下而形成的，相对独立。那么在积极响应式程式设计中，它的亲密关系是变得更加紧密的上游与下游的亲密关系。
因为 Stream，顾名思义，是流的含义，被观测者在流的入口产生该事件，观测者则在流的出口等待数据或该事件的到来。
在这套流程里，观测者的订户与被观测者的该事件正式发布等一系列操作都直接在 Stream 或者说是框架内部完成的。
Dart 中，我们能使用 StreamController 来创建流：
var controller = new StreamController();controller.add(1);//将数据放入流中
如下面代码所示，创建 StreamController 时必须指定泛型类型来表述能加入 Stream 的数据第一类，下面的 controller 能接受 int 类型的数据，我们使用它的 add 方式就能将数据放入到它的传送带中。
假如我们直接运行下面的两行代码，最终并不会不到任何结果，因为我们还没有为传送带设置接收数据的第一类：
var controller = new StreamController();controller.stream.listen((item)=> print(item));//数据观测者函数controller.add(1);controller.add(2);controller.add(3);
下面的代码中，我们通过初始化 StreamController 内部的 stream 第一类的 listen 方式，就能为 controller 第一类加进窃听那个 Stream 该事件的观测者，那个方式接受三个回调函数，那个回调函数又接受三个我们在 new StreamController()泛型中声明的数据第一类作为参数。
这时，每每我们再次通过 add 方式将数据放入传送带后，就会通告观测者，初始化那个函数，并将传递的数据打印出来：
123
另外，我们也能使观测者在某个时间段后停止窃听 Stream 中传递的数据，在下面代码中的 listen 函数会返回三个 StreamSubscription 类型的订户第一类，当我们初始化它的.cancel()后就会释放那个观测者，不再接收数据：
var controller = new StreamController();StreamSubscription subscription = controller.stream.listen((item)=> print(item));controller.add(1);controller.add(2);controller.add(3);await Future.delayed(Duration(milliseconds:500));subscription.cancel();
Flutter
ChangeNotifier
ChangeNotifier 大概是 Flutter 中同时实现观测者商业模式最众所周知的范例了，它同时实现自 Listenable，内部维护三个 listeners 条目用来存放观测者，并同时实现了 addListener、removeListener 等方式来完成其内部的订户监督机制：
class ChangeNotifier implements Listenable { LinkedList? listeners = LinkedList();@protected bool get hasListeners { return listeners!.isNotEmpty;} @override void addListener(VoidCallback listener){ listeners!.add(ListenerEntry(listener));} @override void removeListener(VoidCallback listener){ for (final ListenerEntry entry in listeners!){ if (entry.listener == listener){ entry.unlink(); return;} }} @mustCallSuper void dispose(){ listeners = null;} @protected @visibleForTesting void notifyListeners(){ if (listeners!.isEmpty) return; final List localListeners = List.from(listeners!); for (final ListenerEntry entry in localListeners){ try { if (entry.list != null) entry.listener();} catch (exception, stack){ //…} }}}
在实际使用时，我们只需要继承 ChangeNotifier 便能具备这种订户监督机制，如下那个 CartModel 类：
class CartModel extends ChangeNotifier { final List items =[]; UnmodifiableListView get items => UnmodifiableListView(items); int get totalPrice => items.length *42; void add(Item item){ items.add(item); notifyListeners();} void removeAll(){ items.clear(); notifyListeners();}}
CartModel 内部维护三个 items 数组，add、removeAll 方式时提供更多给外部操作该数组的接口，每每 items 改变则会初始化 notifyListeners()通告它的大部份观测者。
ChangeNotifier 作为 flutter:foundation 中最此基础的类，不倚赖其它任何上层的类，测试起来也非常简单，我们能针对 CartModel 做三个简单的单元测试：
test(adding item increases total cost,(){ final cart = CartModel(); final startingPrice = cart.totalPrice; cart.addListener((){ expect(cart.totalPrice, greaterThan(startingPrice));}); cart.add(Item(Dash));});
这里，当我们初始化 cart.add(Item(Dash));后，是会触发观测者函数的初始化，同时实现一类由数据的改变驱动该事件执行的监督机制。
Flutter 应用中最传统的状况管理方案是使用有状况 widget 的 setState 的方式，这种方式暴露出来的问题是，大型应用中的 widget 树会非常复杂，每每状况更新初始化 setState 时，则会牵一发而动全身，重建大部份子树，使性能大打折扣。
那么，当将 ChangeNotifier 观测者商业模式应用在状况管理方案中时，便能解决那个问题。设想让每三个最小组件充当观测者，检视应用的状况，每每状况改变时即驱动该局部小组件更新，是不是就能达到这种目的。我们常用 provider 库就应用了那个原理。
provider 内部提供更多了三个 ChangeNotifierProvider widget，能向其子组件暴露三个 ChangeNotifier 实例(被观测者)：
void main(){ runApp( ChangeNotifierProvider( create:(context)=> CartModel(), child: const MyApp(),),);}
在子组件中，只需要使用 Consumer widget 注册登记观测者组件，就能接收到 CartModel 内部数据更新的通告：
return Consumer( builder:(context, cart, child){ return Text(“Total price:${cart.totalPrice}”);},);
这里，使用 Consumer 必须指定要检视的 ChangeNotifier 类型，我们要访问 CartModel 那么就写上 Consumer，builder 最为 Consumer 唯一三个必要参数，用来构建展示在页面中的子组件。
当 ChangeNotifier 出现变化的时候会初始化 builder 那个函数。(换言之，当初始化 CartModel 的 notifyListeners()方式时，大部份相关的 Consumer widget 的 builder 方式都会被初始化。)，重建子树，达到局部更新状况的目的。
Navigator
路由是在 Flutter 应用中常去讨论的话题，在整个应用运行过程中，路由操作也都需要被时刻关注着，它是我们了解用户犯罪行为的一类有效的方式。Flutter 提供更多了一套很方便的观测者商业模式的模型帮助我们同时实现那个功要求。
Flutter 中每一 Navigator 第一类都接受三个 NavigatorObserver 第一类的数组，在实际开发过程中，我们可以通过根组件 MaterialApp (或 CupertinoPageRoute)的 navigatorObservers 属性传递给根 Navigator 组件，用作检视根 Navigator 的路由犯罪行为，这一组 NavigatorObserver 第一类是一系列的路由观测者。
Widget build(BuildContext context){ return new MaterialApp( navigatorObservers:[new MyNavigatorObserver()], home: new Scaffold( body: new MyPage(),),);}
路由观测者们统一继承自 RouteObserver，范型类型为 PageRoute，这时，它就能窃听 CupertinoPageRoute 和 MaterialPageRoute 两种类型的路由了：
class MyRouteObserver extends RouteObserver
在我们做实际路由操作，初始化 Navigator 的 pop，push 等方式时，就会按照惯例结点初始化这些观测者第一类相关联的方式：
Future push(Route route){ //… for (NavigatorObserver observer in widget.observers) observer.didPush(route, oldRoute);//…}
这样，观测者商业模式在 Flutter 路由中又完成了那个非常重要的任务。
本文小结
本文内容到这里就结束了，观测者商业模式的场景范例数不胜数，在实际开发中，我们也会经常需要使用到，但我们要记住的是设计商业模式的运用并不是套用模版，而是要根据实际场景找到最合适的解决方案。
对于犯罪行为型商业模式来说，观测者商业模式将被观测者与观测者这两件事物抽象出来，同时实现了代码上的解藕，在实际场景中，观测者可能是关心某种状况的组件，窃听某个该事件的窃听器等等，整体的设计也会变得更加直观，希望大家能在以后的开发中多多使用。
拓展阅读
《Flutter开发之旅从南到北》——第8章路由管理&第9章状况管理观察者商业模式 wikipediaDesign Patterns in Dart什么是Stream简单的应用状况管理
关于本系列该文
Flutter / Dart 设计商业模式从南到北(简称 Flutter 设计模式)系列内容由 CFUG 街道社区核心成员、《Flutter 开发之旅从南到北》作者、小米工程师杨加康撰写并正式发布在 Flutter 街道社区社会公众号和 flutter.cn 网站的街道社区教程栏目。
本系列预计两周正式发布一篇，着重向开发者介绍 Flutter 应用开发中常见的设计商业模式以及开发方式，旨在推进 Flutter / Dart 语言特性的普及，以及帮助开发者更高效地开发出高质量、可维护的 Flutter 应用。
