代码整洁之道【2】

读这本书的目的主要是学习命名、规范组织、开阔视野、了解相关概念，到这篇博文这本书阅读完毕，本书的java代码和一些章节和概念主要通读，2篇读书笔记记录自己认为比较符合个人知识体系的抽象概念、原则、术语等，作为一个回顾手册的作用，也希望能分享给更多的小伙伴。

1.
不要暴露数据细节，抽象形态表述数据，隐藏其实现(活用接口、类的继承和多态)；
对象隐藏数据于抽象，曝露操作数据的函数；
数据结构曝露其数据，没有提供有意义的函数；

2.
对象与数据结构的二分原理：
过程式(使用数据结构)代码便于不改动现有数据结构的情况下，添加新函数；
面向对象代码便于不改动现有函数的情况下，添加新类。
反之：
过程式代码难于添加新数据结构，因为要修改所有函数；
面向对象代码难于添加新函数，因为要修改所有类。

3.
得墨忒耳律：
类C的方法f只应该调用以下对象的方法:
->C
->由f创建的对象
->作为参数传递给f的对象
->由C的实体变量持有的对象
即方法不应调用由任何函数返回的对象的方法。(不吃陌生人的糖果，略略略)
违反的例子:getObject().getName().getString();

4.
数据传送对象(Data Transfer Objects)：一个只有公共变量，没有函数的类；
错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法；
使用异常而非返回码；
给出异常发生的环境说明；
依照调用者需要定义异常类；
别返回null值，别传递null值，避免无法捕捉的NullPointerException异常；

5.
TDD三定律：
->在编写不能通过的单元测试前，不可编写生产代码
->只可编写刚好无法通过的单元测试，不能编译也算不通过
->只可编写刚好足以通过当前失败测试的生产代码
测试代码和生产代码一样重要，都要保持整洁；
每个测试一个断言，每个测试一个概念；
F.I.R.S.T （Fast Independent Repeatable Self-Validating Timely）

6.
保持变量和工具函数的私有性，但并不执着于此；
类应该短小，应该保持单一权责原则(SRP)(类或模块应有且只有一条加以修改的理由)；
内聚性高，意味着类中方法和变量相互依赖、结合成一个逻辑整体；

7.
延迟初始化/赋值
if(para == null)
para = new Class();
return para;
在用到对象之前，不用管这种架空构造，启始时间更短，而且永远不会返回null值；

8.
依赖注入(DI Dependency Injection)，可以实现分离构造和使用，控制反转(IoC Inversion of Control)是一种依赖管理的应用手段；
控制反转将第二权责从对象中拿出来，转移到另一个专注于此的对象中，遵循SRP;
在软件开发领域，关注领域特定语言(DSL Domain-Specific Language)的特定适用性；
无论设计系统还是模块，别忘了使用大概可工作的最简单方案

9.
运行所有测试、重构代码、消除重复、使用更有表现力的变量/函数/方法/类名、尽可能减少类和方法来迭代整个系统；
像写作文打草稿一样逐步渐进的打磨你的软件系统；

10.
重构应该遵循的原则：
->保证系统能够正常工作
->让系统正确的、对的运行；

11.
BAD
注释：不恰当的信息；废弃的注释；冗余的注释；糟糕的注释；注释掉的代码；

函数：过多的参数；输出参数；标识参数；死函数

一般性问题：一个源文件存在多种语言；明显的行为未被发现；不正确的边界行为；忽视安全；重复；错误的抽象层级上的代码；基类依赖派生类；信息过多；死代码；垂直分隔；前后不一致；混淆视听；认为耦合；特性依恋；选择算子参数；晦涩的意图；位置错误的权责；不恰当的静态方法；使用解释性变量；函数名称应该表达其行为；理解算法；逻辑依赖改为物理依赖；用多态替代if/else或switch/case；遵循标准约定；用命名常亮代替魔术数；准确；结构基于约定；封装条件；避免否定性条件；函数只做一件事；掩蔽时序耦合；别随意；封装边界条件；函数应该只在一个抽象层级上；在较高层级放置可配置数据；避免传递浏览；

名称：采用描述性名称；名称应与抽象层级相符；尽可能使用标准命名法；无歧义的名称；为较大作用范围选用较长名称；避免编码；名称应该说明副作用

测试：测试不足；使用覆盖率工具；别略过小测试；被忽略的测试就是对不确定事务的疑问；测试边界条件；全面测试相近的缺陷；测试失败的模式有启发性；测试覆盖率的模式有启发性；测试应该快速；