Java 必知必会——Unix哲学和组合思维

组合思维可以说是来自于Unix的设计哲学：主张组合设计，而不是单体设计；主张使用集体智慧，而不是某个人的特殊智慧。

Unix哲学发展至今，诞生了无数优秀的设计原则和最佳实践。其中，对于编程来说，最有价值的原则就是 Peter H. Salus 总结的三条原则：

• 编写可以做一件事并且做的很好的程序。
• 编写程序以协同工作。
• 编写程序来处理文本流，因为这是一个通用接口。

这三条规则可以理解为：简单完备性、组合思维和数据驱动。

1. 简单完备性

这其实就是 “ 简单原则 ”，其宗旨就是：一个程序只做一件事，并且做得很好。

这条原则的主要的作用就是能够极大地减低软件复杂度。

1.1 软件复杂度

问题来了，什么是软件复杂度。

​ 软件复杂度（区别于计算复杂度）是对影响软件内部关联关系的属性的描述。

​ —— Manny Lehman 《软件演进法则》

其实就是，代码之间的互相影响越多，软件就越复杂。

软件复杂度一般来自三方面：

• 代码库规模： 代码库规模越大，通常越复杂，但代码行数和复杂度并不是正相关。比如，同样的类库， Java 代码类库 通常会比 C++ 类库的代码行数更多，其实是由于语言特性导致，并不一定更复杂。
• 技术复杂度： 也就是不同的编程语言、服务架构等对于开发人员理解的难易度。
• 实现复杂度：不同开发，对于需求理解不同，代码实现就不同。

1.2 如何降低代码复杂度？

• 代码库规模：减少硬编码来控制代码量。

  比如，以策略模式替代大量 if-else；使用工具类减少从重复代码调用；语言特性的一些类库，如 Java 8 的 lambda 表达式。

• 技术复杂度：在设计时做好技术选型。

  简单来讲，系统设计时要确认好技术方案，是否会引入过于复杂的组件，或是否存在过渡设计；确认系统设计方案的后续可维护工作，是否存在过高的学习成本等等。

• 实现复杂度：使用统一的代码规范。

  使用同一套编码规范，能够尽量统一不同开发之间的编程风格，减少适应代码风格的维护成本。

2. 组合思维

2.1 为什么需要组合思维？

开发时，即使在项目前期做了大量的准备工作，也不能完全比需求的变化，一旦需求发生变化，往往就意味着代码要发生变更。

那么，组合思维就显得十分重要，把软件设计成独立组件并能随意组合，才能真正应对不断变化的需求。

2.2 如何做到组合思维？

• 解耦：代码依赖关系越多，就越复杂，只有将代码不断拆分，才更容易理解它们之间的关系。

  其实，就是常说的设计时要尽量分离接口与实现，程序应耦合在标准和规范上，而不是耦合在具体代码实现逻辑上。

• 模块化：模块化的深层含义是可替换的一致性。

  比如，想使用 RPC 协议，可以选择 Dubbo 、gRPC 等框架，这两个框架的基础是 RPC 协议，无非只是实现的组件框架不同，可以互相替换，实现的功能是一致的。

  也就是说，一致性指的是不同框架通过实现同一个功能来保持功能的一致性。

上面说了那么多，其实就是老生畅谈的高内聚、低耦合，模块内部尽量聚合以保持功能的一致性，模块外部尽量通过标准来耦合。

简单来说，通过提供机制而不是策略，来保证软件的自由组合，每次需求的修改，仅仅是策略调整，不需要更改整个系统机制。

3. 数据思维

目前的互联网应用中，绝大部分都是数据密集型，而不是计算密集型。

也就是说，设计时，做重要的是要彻底了解这个需求的数据是什么：如何组织数据结构，如何产生数据、如何处理数据、如何存储数据、如何展示数据、如何删除数据。

简单来说，就是数据驱动编程：编程中重要的是数据结构，而不是算法。

因为灰度发布和客户端程序版本升级的问题，当数据结构发生变化时（添加数据库字段等），往往会出现新旧代码及新旧数据格式在线上环境共存的问题，因此，要考虑数据的兼容性。

数据驱动编程，意味着需要把代码和代码作用的数据结构拆分，来达到改变程序逻辑时，仅需编辑数据结构，减少代码修改的目的。

简单来说，就是设计时需要考虑数据本身能支持哪些场景？

是否需要预留接口功能或抽象相关模块，避免一次性代码的产生，每次需求变更都要出现大量代码变更，也就是设计时要以解决数据变化为中心，而不是仅关心当前需求对于数据的要求。

参考资料：
《趣学设计模式》https://kaiwu.lagou.com/course/courseInfo.htm?courseId=710#/detail/pc?id=6863