订阅发布模式的优缺点

[smallnewer]

经常问别人这个问题。随便记录下我的看法。

优点：
为解耦而生，方便各模块不去污染其他模块的代码，在自身内完成逻辑编写。

缺点：

1. 在程序启动往往因为订阅时机差异而导致没有捕获到预期的订阅通知。
2. 同上，接不到订阅时，会依赖从其他地方取一个初始值。增加了逻辑，逐渐复杂。
3. 接上，是因为由于业务代码的特点，模块依赖是网状的，每个模块都可能依赖多个模块。再加上订阅时机的问题，出各种疑难杂症是很容易的。另外没有IDE加持，追踪依赖关系较为痛苦。
4. 结合生命周期，卸载真的挺烦人的。总担心会忘了，有的同学没这个担心，因为他根本不释放。
5. 发生内存泄露时，贼难定位。追到一个事件发布时会泄露，这个事件有几十个模块在监听-。-注释掉任何一个程序就可能跑不起来。只能寄希望于profile tool，但真的不是所有时候都能分析出来。
6. 事件名都是字符串常量，也挺占内存的。压缩也压不掉。

综上，该模式适合用在框架、类库等较底层的代码中，各模块依赖关系清晰，顺序明确，可以引入该模式做解耦。但要在业务代码层，少量使用亦可，最佳的仍旧是更上一层的单向数据流封装。