代码大全2札记：软件架构中的设计

前言：软件架构中的设计一章，主要的point有软件的首要技术使命就是管理复杂度、减少在同一时间锁关注的本质性复杂量、设计是一种启发式过程、好的设计要有迭代、信息隐藏。

设计中的挑战

1. 设计是一个险恶的问题：设计不可能从一开始就是完美的，人们在设计时会不明所以的忽略掉一些重要的问题，从而导致设计最终面对失败。
2. 设计是个了无章法的过程：设计过程中会发生很多错误，但正是设计所需要的。
3. 设计就是确定取舍和调整顺序的过程：设计者的关键工作就是找出发生冲突的特征，进行平衡。
4. 设计受到诸多限制：在进行设计的时候，需求者会给你提各种要求，比如说时间、金钱、质量，那么必须用把资源利用率达到最大。
5. 设计是不确定的：每一个对同一种需要作出的设计都是不同的。
6. 设计是一个启发式过程：设计的过程中会带来很多启发，比如说从错误的事件中得到另外一个新的设计。
7. 设计是自然形成的：设计需要不断的评估、讨论、试验、修改而成的。

关键的设计概念

1. 管理复杂度
   • 偶然的难题和本质的难题：我认为是这样的概念，举个例子，NBA的每场得分，从本质上来看，每场最高得分不可能超过200分，那么我们是否可以将每场的最高得分限制为200分呢，显然这样会遇到一个问题，就是说假如出现某种偶然情况，竞争的两支球队，一支不防守，另外一支疯狂进攻，那么得分可能会超过200分，那么我们为了考虑这种偶然的情况，显然我们不可能把分数最高设置为200分。
   • 管理复杂度的重要性：设计软件有两种方式，第一种是设计非常简单，看上去明显没有缺陷；第二种是设计非常复杂，看上去没有明显缺陷。那么能将复杂度管理好，是非常重要的。
   • 如何应对复杂度：
     • 把任何人在同一时间需要处理的本质复杂度的量减少。
     • 不要让偶然的复杂度无谓增长。
2. 理想的设计特征：当我解决问题时，从不考虑美感。只想着如何解决问题，然而一旦解决了问题，如果解决方案不够优美，那么我知道做错了。
   • 最小的复杂度：设计要简单易于理解。
   • 易于维护：为需要维护的程序员着想。
   • 松散耦合：做设计时让程序的各个组成部分之间关联最小。
   • 可扩展性：能够增强系统的功能而不破坏原有机构。
   • 可重用性：当前系统的组成部分要能够在其他系统中重复使用。
   • 高扇入（让大量的类使用某个既定的类）、低扇出（让一个类少量或者适中的使用其他的类）
   • 可移植：可以方便的移植到其他系统。
   • 精简性：伏尔泰“一本书的完成，不在于不能再加入内容，而在于不能删除内容的时候”。
   • 层次性：尽量保持各个分解层的层次性，例如要在原来旧的代码上进行开发，假如就的代码不够优秀，那么就需要设计一个层次去和旧的代码进行沟通，同时和新的代码进行连接。
   • 标准技术：要能够使用标准化的、常用的方法，避免使用新颖而不成熟的技术。

设计的层次

1. 软件系统
2. 分解为子系统：整个软件系统被分解为多个不同的子系统后，子系统之间的相互关联要尽可能的少，不能A-B-C-D-E之间来回的关联。子系统分为以下大的种类：
   • 业务规则：该子系统一般会要发生变化，客户的需求在开发过程或者开发完了后都要发生变化。
   • 用户界面
   • 数据库访问
   • 跨平台
3. 分解为类：将子系统适当的分解，其分解出来的类要形成具有特定功能的类。类和对象的关系，就如同模具和实物。
4. 子程序的内部设计：比如说选择不同的算法，比如要使用冒泡还是插入

启发式的设计

1. 找出现实中的对象：先别问系统做什么，先问问它模仿什么。
2. 形成一致的抽象：抽象使你关注事物的共有特性，而暂时忽略其具体的细节。
3. 封装实现细节：封装可以让你看到一个返回Boolean的方法，但是却不让你看到怎么得到的true或者false。
4. 合适的继承：马云和马化腾都是人，但是他们领导的公司是不同的，那么他们两个就可以继承人的属性和方法。
5. 隐藏秘密：需要隐藏的秘密有两种，复杂度和变化源。

找出容易改变的区域

1. 业务规则、硬件依赖、输入输出、状态变量、数据量的限制，这些因素都是容易发生改变的，就需要把这些从系统中进行分离。
2. 预料不同程度的变化。

保持松散耦合

1. 耦合标准：
   • 规模：模块之间要尽可能的小
   • 可见性：模块之间要相互可见
   • 灵活性：模块之间的链接要容易。

查阅常用的设计模式

1. 抽象工厂
2. 适配器
3. 桥接
4. 组合
5. 装饰器
6. 外观
7. factory method
8. 迭代器
9. 观察者
10. 单例
11. 策略
12. 模板方法

其他的启发方式

1. 高内聚性：类内部的子程序或者子程序所在的代码在支持一个中心的紧密程度。
2. 分层结构：建筑工程师在设计图纸的时候，总是先画起轮廓，然后再填充细节。
3. 契约：有的时候，约定俗成很好。
4. 分配职责：就比如在包名建立时，就需要区分controller和service。
5. 为测试准备
6. 避免失误：充分思考风险。
7. 考虑蛮力：有的时候拿不准注意的时候就用蛮力解决，就像实现消息包发送时，如果没有好的解决方案，就使用轮询解决。
8. 画图：在设计时，画一些粗糙的图来帮助自己理清思路。
9. 如果你被当前的问题难住了，那么就跳出来去思考其他问题，或者干脆睡一觉，因为大脑在休息的时候，依然会尝试寻找答案，那么其可能会得到正确答案。

设计实践

1. 迭代：设计是一个过程，等你从头做到尾后，尽量从头再来一遍。
2. 分而治之：把复杂的系统分解。
3. 自上而下和自下而上：一般情况下，我们从顶层开始思考问题往往不错，但是有的时候从已知的底层反推也会祝你的设计一臂之力。
4. 建立试验原形：在你搞完设计后，不能纸上谈兵，要尝试实践测试。
5. 合作设计：寻找你的同伴，或者能给你帮助的人一起做设计。
6. 设计要适当：要懂得舍取
7. 记录设计成果：比如说记录到SVN、总结邮件、代码注释、UML

设计所有细节和不做任何设计

      极端的设计方案不可取

设计实践：

1. 设计经过了很多迭代，找出最合适的一种
2. 同时采用自下而上和自上而下的方案
3. 为可能出现的问题进行验证
4. review方案
5. 记录设计成果

标签：代码,札记,200,复杂度,分解,软件架构,设计,子系统,大全
来源： https://blog.51cto.com/u_2324584/2937290