代码设计感悟-设计方案
设计出一个方案，中间肯定是有很多暂时无法解决的问题的，这样不必过分纠结，通过迭代的方式，暂缓一下，出去散散步喝喝茶，可能有新的角度新的方案。
除了迭代这个方式，还有分而治之的思路，将大方案拆分成小的，然后分别处理。增量式的改进是一种管理复杂度的强大工具。
两种设计方法：
- 自上而下
- 自下而上
程序员或者大多数人都擅长第一种，自上而下的设计方式，拆分任务，这种方案对细节的把控可能有疏忽，但是这种细节的信息隐藏起来，其实是比较好的。另一种自下而上的方式，如果之前你已经设计了类似的方案，就可以多考虑一下复用，但是如果是从零开始，你会发现你手中的零件不足以拼出来一个完善的系统。所以其实这两种方式不冲突，要根据实际相互结合，才能设计出一款大而精的产品。 - 软件的首要技术使命就是管理复杂度。以简单性作为努力目标的设计方案对此最有帮助
- 简单性可以通过两种方式实现：一是减少在同一时间所关注的本质性复杂度的量，二是生成不必要的偶然的复杂度。
- 设计是思考的过程，固执一种方式单一方法是会损害创新损害程序的
- 好的设计都是迭代的。尝试设计的可能性很多，最终方案会越来越好
- 想你洗隐藏是非常有价值的概念。通过问自己“应该隐藏些什么”能够解决很多困难的设计问题
软件构件中的设计
一个项目的软件复杂度非常重要
设计时考虑：最小的复杂度、易于维护、松散耦合、可扩展性、可复用性、高扇入、低扇出、可移植性、精简性、层次性、标准技术
高扇入：大量的类使用某个特定的类。
低扇出：让一个类里少量或射中的使用其他类
抽象 信息隐藏
怎么信息隐藏 找出公共的地方被多处引用的
找出容易改变的区域：1.找到看起来容易变化的项目
2.把容易变化的项目分离出来
3.把看上去容易变化的项目隔离开来
常见的容易变化的区域
- 业务规则例如公式
- 对硬件的依赖 例如与硬件通讯的接口
- 输入和输出
- 非标准的语言特性
- 困难的设计区域和构建区域 例如 复杂的业务逻辑 大概率质量不高需要重构修改
- 状态变量 可以用枚举
- 数据量的限制
保持松散耦合度
耦合度表示类之间或者程序质检的关系的紧密程度。设计目标时耦合度小、直接的、清晰的类或子程序，是他们与其他类或者子程序关系尽可能灵活。
例子 一个子程序被多地调用，入参是一个对象， 大家都传这个对象是没问题的，但是如果说这个子程序只需要几个关键字段进行做入参，那么就比入参是一个对象来的更松散