优雅のJava（五）—— 优雅的观察对象与订阅信息 观察者模式 好莱坞原则

专栏导航

优雅のJava（零）—— 面向问题的学习

前言

这篇主要是阐述一种思维 概念 怎么观察 是最高效优雅的

好莱坞原则

就好像比起班主任挨个问每个同学的作业写了没 VS 每个同学自己汇报 哪个效率高的问题 有个叫好莱坞原则的东西 编程导论有提到

好莱坞原则：“不用找我们，（时机成熟）我们会找你的 (don’t call us, we’ll call you)”
就是说在好莱坞，把简历递交给演艺公司后就只有回家等待。由演艺公司对整个娱乐项的完全控制，演员只能被动式的接受公司的差使,在需要的环节中，完成自己的演出。

其实 类似的思维贯穿了很多设计模式

工厂模式的思路借鉴

比如 前边讲到的工厂模式 就是 不用你去找每个类怎么制造 而是每个类提供他的BeanFactory 你执行就好

IOC的思路借鉴

还有后边第六篇要讲的 IOC控制反转 不需要你这个调用者 去操心被调用组件的生命周期管理（就是啥时候创建啥时候销毁） 而是容器主动根据你的需求 注入 送到你跟前

实际上这篇也是为第六篇做铺垫

问题核心

观察者模式定义了一个基本的 一对多的关系下 我们应当怎么操作 观察
当一个对象的状态发生改变 所有依赖这个对象都会被通知

我们观察这个对象 就好像订阅（subscribe） b站Up主 订阅这个 主题subject 而不是我们每隔五分钟就去給Up发私信 问 你更新了没呀（那估计要被Up鲨害了：）

然后Up如果更新了（异步），通知我们一声 推送push一个链接就好了
之前每五分钟问Up的操作 被称为Pull 拉取

当然是推送的效率更高 拉取就类似轮询操作

即时通讯的思路借鉴

玩过即时通讯的兄弟应该知道只是轮询 对系统性能的损耗是有多大！但是没办法 服务器并不能主动的通知客户端（HTTP无状态） 那些网络上的“订阅” 底层仍然是使用轮询实现 但可能更聪明 比如长轮询 或者如websocket发送心跳包维持连接的方式

GUI设计上的思路借鉴

还有就是 比如玩GUI的同学 可能见过几个关键侧 event事件 trigger 触发 这里同样适用观察者模式！我们想检测这按钮click的事件 难道靠轮询 拉取这个按钮的状态吗？假设1w个按钮 请问怎么拉取 又怎么判断哪个按钮被按下了呢？ 相必非常耗损性能 但是如果设计成 按钮click以后 执行clickHandler 触发click事件 交给控制器处理 那就高效很多

当然 玩过电子 硬件二维键盘的同学应该知道 单片机检测按键按下 就是采用pull 单片机IO端口拉取（采样）电信号状态的方式来的 因为没啥别的好办法 最多做个降维 比如4X4 我只需要探测行 列 共八个IO口 就能确定几行几列的按钮被按下了 而不是4*4=16个IO

后记

总之 观察者模式很简单 但是贯穿了很多设计模式 我们面对一对多的情况 甚至设计数据库表结构的时候 都可以想想应该怎么处理为好

而多对多的应对之道 也就是拆成一对多+多对一

下一篇 第六篇 我们也将看到 依赖问题的解决上 是如何借鉴到观察者模式的些许思路

专栏导航
优雅のJava（零）—— 面向问题的学习