笔记：代码整洁之道
命名：
1、有意义，名副其实：降低代码的模糊度，明确说明代码的用途；
2、避免误导：accountList的类型最好就是List；
3、避免使用多个不同之处较小的名称；
4、避免使用字母l和O，因为它们像数字1和0；
5、做有意义的区分，只有意义不同时才使用不同的名字；
6、废话是无意义的区分，是冗余；
7、使用可搜索的名称：用宏定义数字比直接用数字好，避免使用单字母变量和数字常量；
8、不必使用带类型的匈牙利标记法；
9、避免成员变量使用类名前缀；
10、类名和对象名一般都是名词和名词短语；
11、方法名一般是动词和动词短语；get,set,is前缀；
12、使用解决方案领域内的名称；
13、添加有意义的语境：使用有意义的前缀，创建一个类并将变量声明为成员变量；
14、命名要精确：不要添加无意义的语境；
函数：
1、短小：函数中的缩进层级不应该多于一层或者两层；
2、函数应该做一件事，做好一件事，只做一件事；
3、每个函数只有一个抽象层级，其他的交给下面的抽象层来做；
4、判断函数只做了一件事：不能分函数区段；
5、阅读代码，自顶向下规则：每个函数后面都跟着下一个抽象层的函数；
6、如何让switch只做一件事：通过类工厂创建实际类并返回父类引用，再使用抽象类（父类引用）调用实际类重写的函数；
7、使用描述性的名字；
8、函数参数：为了便于测试，应该少于2个；
9、一元函数的3种形式：
①询问关于参数的问题（判断），②转换参数的内容（要有返回值），③参数是个事件（无返回值）
10、如果函数超过2元：应该将其中的某些参数封装成类；
11、函数名字：动/名词形式；
12、避免使用输出参数：如果需要，应该修改所属对象的状态；
13、一个函数要么做一件事（指令），要么回答一件事（询问）；
14、使用异常代替返回错误码：这样错误代码可以从主路径代码中分离出来，避免嵌套；
15、分离try/catch块：集中在一个函数中；
注释：
1、 整洁清楚的代码比注释要好得多；
2、 真正好的注释就是考虑不用写注释；
3、 需要注释的地方：提供法律信息；解释方法的意图；提供警告信息；
4、 ToDo注释，提示尚未完成的工作；
5、 避免括号后面的注释，应当减少嵌套，写成方法；
6、 删掉被注释掉的代码；
7、 注释就是一种失败；
格式：
1、 垂直上的间隔：不同的逻辑之间用空格间隔；
2、 垂直上的靠近：关系密切的逻辑要靠近才会更加清晰；
3、 变量在离使用最近的地方声明；
4、 相关函数：放在一起，调用者放在被调用者的上面；
5、 概念相关：命名模式相同，应该放在一起；
6、 水平方向：以不拖动滚动条为准则；
7、 =，+=等前后的空格可以起强调的作用；
8、 缩进
9、 团队规则
对象和数据结构（过程式代码）：
隐藏实现关乎抽象，并不是简单的添加取值器和赋值器；
1、 对象和数据结构的反对称性：
过程式代码便于在不改变既有代码的同时，添加新的函数（过程）；
面向对象便于在不改变既有函数的情况下，添加新的类（对象），但是如果抽象类添加新的函数，就需要修改抽象类的所有子类；
2、 数据结构应该只有公共变量；对象应该只有私有变量和公有函数；
3、 对象暴露行为，隐藏数据；便于添加新对象类型而无需修改既有行为，同时也难以在既有的对象中添加新行为。
数据结构暴露数据，没有明显的行为；便于向既有数据结构添加新行为，同时也难以向既有函数添加新数据结构。
错误的处理：
1、 不要返回null值：这样的话调用者就要处理null，增加工作量；
解决：抛出异常或者返回特例对象；
2、 不要传递null值：
3、 异常的处理：抛出异常或者返回特例对象；如果是调用第三方api可能产生异常，可以新建一个方法或异常类将第三方api打包；
4、 避免使用可控异常（checked exception）：因为处理它们需要修改函数头，违反了开放-闭合原则；应该使用不可控异常（runtime exception），
保持边界整洁：（电子书缺失）
1、 学习性测试：在项目中引入第三方api的新版本，测试项目是否正常工作；
2、 处理边界问题方法：用新类包装第三方api；用adapter模式将我们的接口转换为第三方提供的接口；
更多设计模式：http://blog.csdn.net/qinysong/archive/2006/08/09/1041818.aspx
单元测试：
1、测试驱动开发，整洁的测试有助于进行代码的改动；
2、整洁测试的标准：可读性；
3、双重标准：由于运行环境的差异，测试代码和生产代码可以有不同的标准，如效率、内存等；
4、单个测试的断言数量应该最小化，只测试一个概念；
5、F.I.R.S.T规则：
F fast:测试需要频繁运行，因此要能快速运行；
I Independent：测试应该相互独立；
R Repeatable：测试应当能在任何环境中重复；
S Self-validating：自足验证，测试应该能看到成功与否的结果；
T timely：测试应该及时编写，应该恰好在生产代码之前编写；
类：
1、类的组织：自顶向下原则，变量列表（公共先于私有，静态先于实体），方法列表（工具方法紧跟在所属方法之后）；
2、类应该短小：类名越明确，类的职责就越清晰；
（1）每个类单一权责，只有一个修改它的原因，并与少量的其他类协同完成工作；
（2）内聚：类中含有最少的变量，且每个方法都使用每个变量，此时内聚度最高，类应该是内聚高的；
3、隔离修改：具体类实现细节，抽象类只呈现概念，利用接口和抽象类可以隔离因为细节的改变而带来的改变类的风险；
系统：
1、构造与应用代码应该隔离开：就好像建设大楼时，构建大楼的吊车、铲车之类的东西，在大楼投入使用时已经完全不存在一样；软件系统应该讲启动过程和启动过程之后的运行时逻辑分开，在启动过程中创建应用对象，也会存在相互的依赖。
public Service getService(){
return new MyServiceIml(...);
}
这种延迟化赋值的好处是：在使用对象之前不用关心这种架空构造；坏处是：必须实现这个构造方法，不然无法编译，即使这个对象在运行时永远不会被使用。
解决方法：
（1）分解main，将系统中的全部构造过程搬迁到main或者main模块中：main函数创建对象，再将对象传递给应用，应用直接使用；
（2）工厂，可以让应用控制实体创建的时机；
（3）依赖注入，控制反转IoC是依赖管理的手段，它将应用需要的依赖对象的创建权责从对象中拿出来，放在一个专注于此事的对象中，并通过依赖注入（赋值器）将依赖对象传递给应用；
2、扩容
AOP，面向方面变成。Java中三种方面和类似方面的机制：代理，纯AOP框架，AspectJ
（1）Java代理：Proxy.newInstance(被代理接口，InvocationHandler h)方法执行后，被代理类的所有方法都会被加上Handler的处理逻辑，这是简单的AOP，但是太复杂；
（2）纯AOP框架：Spring AOP（需进一步了解）
（3）AspectJ语言
最佳的系统架构由模块化的关注面领域组成，每个关注面均用纯Java对象实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来。这种架构能测试驱动，就像代码一样。
2011-6-24 读到173页
