《代码大全2》读书笔记--2

第五章：软件构建中的设计

好的高层次设计能提供一个可以稳妥容纳多个较低层次设计的结构。

设计是一个“Wicked Problem” – 你必须把这个问题“解决”一遍以便能够明确地定义它，然后再次解决该问题，从而形成一个可行的方案。

软件设计的最重要目的是管理复杂度。有两类复杂度：

• 本质的：一件事物必须具备，不具备就不再是该事物的属性。比如业务逻辑。

• 偶然的：碰巧具有的属性。比如集成环境，编程工具等等。

大脑没法装下整个程序。好的设计，让人在一个时刻可以只专注于一个特定的部分。

你可以把它想做是一种心理上的杂耍（边抛边接：通过轮流抛接，使两个或两个以上的物体同时保持在空中） – 程序要求你在空中（精神上）保持的球越多，你就越可能漏掉其中的某一个，从而导致设计或编码的错误。

理想的设计特征

• 最小的复杂度。要避免做出“聪明的”设计。因为“聪明的”设计往往都是难以理解的。如果你设计的方案不能让你在专注于程序的一部分时安心地忽视其他部分的话，这一设计就没什么作用了。

• 易于维护

• 松散耦合

• 可扩展性

• 可重用性

• 高扇入。高扇入就是说让大量的类使用某个给定的类。这意味着设计出的系统很好地利用了在较低层次上的工具类。

• 低扇出。低扇出就是说让一个类里少量或适中（小于7个）地使用其他的类。

• 可移植性

• 精简性。伏尔泰曾说，一本书的完成，不在它不能加入任何内容的时候，而在不能删去任何内容的时候。

• 层次性。假设你正在编写一个新系统，其中用到很多设计不佳的旧代码，这时你就应该为新系统编写一个负责同老代码交互的层。在设计这一层时，要让它能隐藏旧代码的低劣质量，同时为新的层次提供一组一致的服务。

• 标准技术

优秀设计师的一项重要特质就是对变化的预期能力。好的程序把变化所带来的影响限制在一个子程序、类或者包的内部。

测试友好的设计，往往是好的设计。

“你在应用某种设计方法时越教条化，你所能解决的现实问题就越少”。请把设计看成是一个险恶的、杂乱的和启发式的过程，不要停留于你所想到的第一套解决方案，而是去寻找合作，探求简洁性，在需要的时候做出原型，迭代，并进一步迭代。你将对自己的设计成果感到满意。

 

第六章：可以工作的类

1、类的接口应该提供一致的抽象。很多问题都是由于违背该原则而引起的。

2、类的接口应该隐藏一些信息，如某个系统接口、某项设计决策、或一些实现细节。

3、包含（组合、聚合）往往比继承更可取，除非是要对一个“is a”的关系建模。

4、限制继承的层次，继承是一种有用的工具，但它却会增加复杂度，这有违软件的首要使命-管理负责度。

5、类是管理复杂度的首先工具。要在设计类时给予足够的关注，才能实现这一目标。

6、尽量减小类和类之间相互合作的范围，让以下几个数字最小：

①所实例化的对象的种类；

②在被实例化对象上直接调用的不同子程序的数量；

③调用的“通过其他对象返回的”对象的子程序的数量；（A通过调用B的返回值C来调用C的方法，）

7、警惕有超过约7个数据成员的类。

第七章：高质量的子程序

1、为什么要创建子程序？

提高程序的可读性，减少以及隔离程序复杂度，提高代码复用率，在代码变更时减少带来的影响（功能变更，变更导致的测试），可移植性，方便后期优化，隐藏复杂逻辑结构等的实现细节......

2、如何设计子程序？

保证子程序功能的内聚性，既一个子程序只完成一个功能。避免其它的内聚性，比如逻辑上的内聚性，顺序上的内聚性等。

3、什么是好的子程序名字？

能够描述子程序所做的事情，使用动宾结构，并且对返回值有所描述，比如checkOrderInfo，使用对仗词（比如get/set,create/destroy），一般命名长度为9～15个，在一个项目里最好给一些通用的操作确立命名规则（比如创建、更新记录时），避免模糊命名（比如detail）；

4、子程序可以多长？

考虑事项：子程序的功能的内聚性，嵌套的层次，变量的数量，决策点的数量等；

研究表明应该一般不超过200行，

5、如何使用子程序参数？

按照输入、修改、输出的顺序排列参数；

如果几个程序都用了类似的一些参数，应该让这些参数的排练顺序保持一致；

不要把子程序的输入参数用作工作变量，工作变量最好在子程序中创建，保证参数尽量不被改变；

把子程序的参数个数限制在大约7个以内，且保证每一个参数都被用到；

为子程序传递用以维持其借口抽象的变量或对象，传递给子程序什么类型的参数，应该为对子程序而言，哪种方式对子程序更方便；

 

 

第八章：防御式编程

1、什么是防御式编程？为什么需要？

防御式编程不是指不让别人批评你的代码，而是指确保你要承担的责任，保证你的方法不会因为传入错误数据而破坏，看似微小的防范，收益可能大于你的想象，能够让错误更容易发现，修改，并减少对已经编写代码的修改

2、如何使用防御式编程？

在开发阶段，建议不从产品角度考虑，建议让错误暴露的越明显越好，能更快的排查错误；在产品上线时，防御式编程的代码可能影响性能以及体验，需要适当修改，但是需要根据场景考虑，比如银行设备以及普通网站，不同产品，错误处理方式不一样；

隔离程序与参数，即对参数进行验证，使之能包容错误造成的损害，并进行适当处理；

3、如何对错误进行处理？处理的方式

需要根据实际场景，程序是更需要健壮性还是正确性，一般普通的消费产品更倾向于健壮性，但和数据相关，则更倾向于正确性；建议在架构设计上就决定好如何处理错误，是异常还是其他的方式。

4、关于异常

避免在构造和析构函数中使用异常；考虑创建一个集中的方式处理异常，能够为一些与异常有关的信息提供集中的存储；把项目中对异常的使用标准化，考虑创建抛出异常的基类，这样就能把记录日志、报告错误等操作集中起来并标准化；不滥用异常，应该在异常和其他错误处理手段进行权衡，如果某些错误能局部处理，那就局部处理它；

标签：代码,读书笔记,--,复杂度,参数,设计,内聚性,子程序,大全
来源： https://www.cnblogs.com/lixiaoy/p/14159711.html