第二部分:创建高质量的代码

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

“在大型项目中,设计可能会详细到让编码工作近乎机械化”

“在小型项目中,设计可能就是指用伪代码写个类的接口,或者询问旁边的程序员那个模式好,画几个类的关系图”

——基本没有经历过大型项目,小型项目描述的过程跟我接触的非常的相似,最多多个设计评审。

“当没人知道对一处代码的改动会对其他代码带来什么影响的时候,项目也就停止进展了”

——得多复杂,多糟糕的项目才会到这个地步啊,没有体会过。

因为项目主要是网络的,没有什么雇员、雇主之类很容易抽象的对象,所以制作的类基本都是c子程序和数据的集合体。不知道是不是不对,不过也没感觉出来不对啊。

“信息隐藏在不断增长、大量变化的环境里尤其有用”

刚开始的代码里面把所有的私有变量都加了get、set,但是慢慢就觉得麻烦,全部都公开了,感觉项目一个人维护,全部私有变量都封装,有时候没感觉出来什么意义,如果个别需要特别处理的变量才封装成方法。

不知道得大到什么程度、或者变动到什么程序,才有明显的意义。或者说,我没有感觉出太大的好处。

“不要使用布尔变量做状态变量,请使用枚举”

——这个比较有道理,因为如果从2种变成为3种类型,修改是个累人的活。

P117 写总结邮件这点不错,每次讨论后,经常有遗忘,或者有人记错了,导致争论和疑问。

 

第六章:可以工作的类

“不懂得ADT(抽象数据类型)的程序员只是把稍有关系的子程序和数据堆在一起,叫做类。”

——感觉自己就是这样,不过看完了这章,感觉就是教你把私有成员隐藏起来,隐藏实现细节,除了接口全部黑盒。

继承与包含,我用的包含最多,继承最少。

一直讨厌使用继承,最大的原因是用source insight看代码不方面,老是跳到基类的方法里面去了。不知道什么阅读工具会比较好。

“当你想让基类控制接口,用继承。当你想染自己控制接口,用包含”

用继承主要是放在list里面方便,不过我平时都是用一个类,然后包括一个void*,来访那些包含的类,再用一个type变量标记是哪种类。

P155

“避免创建万能类”——有时候视图控制数据分离,难道不是这种结构作为过渡吗?

“消除无关紧要类”——类比结构体放数据方便很多,为什么不能出现专门放数据但是没有行为的类?

C++中,只有virtural的方法才能被覆盖,java默认方法都能被覆盖。

 

第七章:高质量的子程序

子程序的参数不要超过7个,可以做成结构体,这样增加一个参数的时候会比较方便。

不要出现神秘值,用常量定义或者用枚举来替代100,4.0,3.14之类的常量。

子程序要尽量单一而明确的任务。

避免把输入值当做工作变量。

 

子程序可以避免代码重复,更易懂,提高可移植性,未来去优化也比较方便。

 

第八章:防御式编程

“主要思想:传入错误的参数也不怕”

断言是不错的方法,但是linux里面用断言感觉不是很好,因为屏幕打印有什么用处,还不如打印到日志里面去,狠点的话,打印日志后退出程序好了。

处理错误有多种情况,不错网络情况估计就是报警和重试了吧。

在正确性和健壮性之间选择。

“只有真正的例外才抛出异常,异常应该和断言一样,是永远不应该发生的事情”

——这个好像跟com不符合哦,com主要是抛出异常的,尤其是解码的com,抛出的异常种类那叫一个多。

——这里的理由是“异常弱化的了封装性”

P203页批评程序员用异常返回错误是为用而用

——记得以前我上学的时候,一个同学还说他师兄是真正的面向对象,所有返回错误值的地方都用异常处理,当时我们崇拜了一阵子。不过这里也未必全对,毕竟是一本书。

“删除一个对象之前把它填满垃圾数据”

——够狠,也是个好主意,这样不会出现有时候出错有时候正常的情况了,如果以后再试图使用肯定崩溃。

 

 第九章:伪代码编程

1、使用自然语言来精确描述特定的操作。

2、避免使用目标编程语言中的语法元素。(这样会受制于程序语法上的约束)

3、先超出语言来描述解决问题的意图。

4、再以足够低的层次上编写伪代码,以便可以近乎自动的从它生产代码。

5、写好代码后,可以把伪代码当做注释存在。

架构应该提前指明多少资源可用,好确定性能还是可读性优先。

“写一个子程序前先考虑怎么测试它”——感觉很困惑,也没有举出例子,不就是检查输入输出吗?还能考虑什么?