设计模式分享

1. 设计模式漫谈
观察者模式到去中心化

2. 预备
 这不是一次纯分享，我们更鼓励讨论
 可以随时打断
 以下内容都是我的随想，不负政治责任
 禁止对作者人生攻击

3. 简介
 软件设计模式的起源归因于 Christopher Alexander 所做的工作。 作为架构师，
Alexander 注意到在给定的环境中存在常见问题及其相关的解决方案。 Alexander 将
此问题/解决方案/环境三元组称为“设计模式”，架构师在构建设计过程中可通过它以
统一的方式快速解决问题。 二十五年前第一次出版的 A Pattern Language: Towns,
Buildings, Construction （Alexander 等人编著，牛津大学出版社于 1977 年出版）
介绍了 250 多种建筑设计模式，并提供了将此概念融入软件开发领域的基本原则。
 在 1995 年，软件业首次广泛采用了设计模式，因为它们与构建应用程序直接相关。
四位作者 Gamma、Helm、Johnson 和 Vlissides（统称为四人组或 GoF）将
Alexander 的设计模式与他们的作品 Design Patterns: Elements of Reusable Object-
Oriented Software （Addison-Wesley 出版公司于 1995 年出版）中的刚刚兴起的面
向对象的软件开发动向结合起来。 凭着他们丰富的经验和对现有对象框架的分析，
GoF 提供了 23 种设计模式，这些模式分析了在设计和构造应用程序时遇到的常见问
题和解决方案。 在这个出版物之后，设计模式的概念已发展为包含在软件领域中遇
到的很多 问题和解决方案。 事实上，设计模式的广泛采用导致了反模式概念的出现，
这些模式是指通常会使手头问题更加严重而不加解决问题的解决方案。

4. 设计模式原则
 开闭原则
模块应尽量在不修改原代码的情况下进行扩展。
"Open for extension…" A key design principle in Spring Web MVC and in Spring in general
is the "Open for extension, closed for modification" principle.
 里氏代换原则
如果调用的是父类的话，那么换成子类也完全可以运行。
 依赖倒转原则
把父类都替换成它的子类，程序的行为没有变化。
 接口隔离原则
 合成/聚合复用
要尽量使用合成/聚合，尽量不要使用继承。
 最少知识原则
即一个对象应对其他对象有尽可能少的了解。

5. 为什么要使用设计模式
 设计模式并不是万能钥匙（如果世上真有此物的话），但它是一个非常强大的工具，
开发人员或架构师可使用它积极地参与任何开发项目。 设计模式可确保通过熟知和
公认的解决方案解决常见问题。 模式存在的事实基础在于：大多数问题其他个人
或开发小组可能已经遇到并解决了。 因此，模式提供了一种在开发人员和组织
之间共享可使用的解决方案的机制。 无论这些模式的出处是什么，这些模式都利用
了大家所积累的知识和经验。 这可确保更快地开发正确的代码，并降低在设计或实
现中出现错误的可能性。 此外，设计模式在工程小组成员之间提供了通用的语义。
参加过大型开发项目的人员都知道，使用一组共同的设计术语和准则对成功完成项
目来说是至关重要的。 最重要的是，设计模式可以节省您大量的时间 （如果正
确使用的话）。

6. 观察者模式
 面向对象的开发的一个主导原则是，在给定的应用程序中正确地分配任务。 系统中
的每个对象应该将重点放在问题域中的离散抽象上，而不是放在任何其它方面。 简
而言之，一个对象只应做一件事，而且要将它做好。 这种方法可确保在对象之间划
定清晰的界限，因而可提供更高的重用性和系统可维护性。（单一责任）
 一个正确划分任务特别重要的领域就是，用户界面和基础业务逻辑之间的交互。 在
应用程序的开发过程中，需要快速更改用户界面要求，并且不会对应用程序的其他
部分产生连带影响，这是司空见惯的事。 此外，业务要求也可能会发生变化，而这
一切与用户界面无关。 具有丰富开发经验的人都知道，在很多情况下，这两组要求
都会发生变化。 如果没有划分 UI 和应用程序其他部分，修改任一部分都会对整体
造成不利的影响。（解耦合）
 很多应用程序都会遇到以下常见问题：需要在用户界面和业务逻辑之间划分清晰的
界限。 因此，自 GUI 出现以后开发的很多面向对象的框架均支持将用户界面从应用
程序的其他部分中划分出来。 不要惊讶（可能有一点），其中的大部分应用程序采
用类似的设计模式来提供此功能。 这种模式通常称为观察者，它在系统中的各种对
象之间划分清晰的界限方面非常有利。 此外，还会经常看到在框架或应用程序中与
UI 无关的部分中使用这种解决方案。 正如大多数其他模式一样，观察者模式的作用
远远超过了其最初的想法。

7. 模式模型
 逻辑模型
 物理模型

8. 观察者模式的引申
路由模式+观察者 = 消息总线

9. Bus 总线

10. 网络化总线

11. ESB 企业服务总线

12. ESB优点
 不需要写大量的代码
 屏蔽了底层实现
 准确性高
 丰富的行业积累

13. 总线完美？
 中心是昂贵的
 中心是不易变
 中心是愚蠢的
 中心是有原罪
原罪一词来自基督教的传说，它是指人类生而俱来的、洗脱不掉的“罪行”。
圣经中讲：人有两种罪——原罪与本罪，原罪是始祖犯罪所遗留的罪性与
恶根，本罪是各人今生所犯的罪。

14. 总线模式的缺点
 总线的传输距离有限，通信范围受到限制。
 故障诊断和隔离较困难。
 分布式协议不能保证信息的及时传送，不具有实时功能。
 所有的数据都需经过总线传送，总线成为整个网络的瓶颈。
 由于信道共享，连接的节点不宜过多，总线自身的故障可以导致系统的崩溃。
 所有的PC不得不共享线缆，如果某一个节点出错，将影响整个网络。

15. 非对称战争
 问：照你的意见，这次解放战争，主要的战略方针是什么？
 答：我们的战略方针，应该是使用我们的主力在很长的变动不定的战线上作战。中
国军队要胜利，必须在广阔的战场上进行高度的运动战，迅速地前进和迅速地后退，
迅速地集中和迅速地分散。这就是大规模的运动战，而不是深沟高垒、层层设
防、专靠防御工事的阵地战。这并不是说要放弃一切重要的军事地点，对于
这些地 点，只要有利，就应配置阵地战。但是转换全局的战略方针，必然
要是运动战。阵地战虽也必需，但是属于辅助性质的第二种的方针。在地理
上，战场这样广大，我 们作最有效的运动战，是可能的。日军遇到我军的猛烈活动，
必得谨慎。他们的战争机构很笨重，行动很慢，效力有限。如果我们集中兵力在一
个狭小的阵地上作消 耗战的抵抗，将使我军失掉地理上和经济组织上的有利条件，
犯阿比西尼亚的错误。战争的前期，我们要避免一切大的决战，要先用运动战逐渐
地破坏敌人军队的精 神和战斗力。
-----《论持久战》毛泽东

16. 新时代
 微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十
个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件
而不是整个的应用程序堆栈，从而满足服务等级协议。
 相对于早期的互联网（Web 1.0）时代，今天的网络（Web 2.0）内容不再是由专业
网站或特定人群所产生，而是由全体网民共同参与、权级平等的共同创造的结果。
任何人，都可以在网络上表达自己的观点或创造原创的内容，共同生产信息。

17. Decentralized
-- 去中心化
 比特币
 ISIS
 微博
 维基百科
 豆瓣的去中心化（一）
 微服务
中心化：几个经过认证的嘉宾在讲话，所有其他人在听。（上课）
去中心化：每个人都可以讲话，每个人都可以选择听或者讲。（英语角）

18. 社会进化
 原始公社制度
 分封制度 & 联邦制度
 集权制
 分散制度？ 人民公社？
真正的去中心化，是要打破过去以官僚、权力、关系等垄断资源构建的绝对中心话
语权格局，变革以“机构化的中心”为主流的“紧箍咒”，释放每一个人的潜能，让真
正有天赋、有能力、有爱心的人有机会成为新的中心，而不会因为他们没有被机构
贴上“专家”、“权威”的标签而石沉大海。

19. Banished -- 放逐之城

20. 回到问题本身
 最初的设计为了隔离 界面和逻辑
 使用路由+观察者
 EventBus进化成总线
 总线成为链接的要道
 维护ESB的成本高，不易变
 拆除总线
问题的核心仍在于 适合的技术应用于适合的场景

21. 拥抱改变