读程序员的制胜技笔记04_有用的反模式（下）

1. 重新发明轮子

1.1. 发明家的特质就是要用质疑的心态对待所有事物，你从未停下质疑，那你将不可避免地成为一个发明家

1.2. 并非所有的事情都有现成的轮子可以拿来用

1.3. 自己重新写一个新的API，最终调用你使用的库

1.3.1. 你的API应该是极简的，满足你的需求就可以了

1.3.1.1. 自己做自己的甲方

1.3.2. 拥有你自己的支持适配器的方便接口的方法在业界被称为适配器模式(adapter pattern）

2. SOLID原则

2.1. S：单一责任原则（single-responsibility principle)

2.1.1. 一个类应该只负责一件事

2.1.2. 不是一个类做多件事，也就是God类

2.1.3. 一个类的名字应该尽可能简洁地解释它的功能，而不是含糊不清

2.1.4. 如果名字太长或太模糊，就需要将该类拆成多个类

2.2. O：开放-封闭原则(open-closed principle)

2.2.1. 一个类应该为扩展而开放，但为修改而封闭

2.2.2. 类设计成其行为可以被外部修改

2.2.3. 可扩展性是一个设计决定，有时可能并不可取、不实用，甚至不安全

2.3. L：由芭芭拉·利斯科夫(Barbara Liskov)提出的里氏替换原则(Liskov Substitution principle)

2.3.1. 程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的

2.4. I：接口隔离原则(interface segregation principle)

2.4.1. 偏向于较小的、目标明确的接口，而不是泛化的、范围广泛的接口

2.4.2. 这是一个不必要的复杂和模糊的建议，甚至可以说是完全错误的

2.4.3. 分割接口不是基于范围，而是基于设计的实际需求

2.4.4. 如果单一接口不适合这项工作，请随意拆分它，而不是为了刻意满足某些定死的僵硬教条

2.5. D：依赖反转原则(dependency inversion principle)

2.5.1. 代码不应该依赖具体的实现，而应该依赖抽象

2.5.2. 继承将你绑定在一个具体的实现上，违反了该原则

2.5.3. 当你喜欢灵活性并且看到它的价值时，你更喜欢依赖抽象，而在无关紧要的情况下，你会依赖具体实现

3. 不要使用继承

3.1. 面向对象编程(Object-Oriented Programming，OOP)最强调的特点是继承

3.1.1. 在常规的继承中，普通代码和它的变化之间的关系是用父类/子类(ancestor/ descendant)模型来表达的

3.2. 从长远来看，继承带来的问题比它解决的问题要多

3.2.1. 多重继承(multiple inheritance)是首要问题之一

3.2.2. 除了多重继承之外，继承的一个更大的问题是强依赖性

3.2.2.1. 紧耦合(tight coupling)

3.2.2.2. 依赖性是万恶之源

3.3. 组合(composition)

3.3.1. 你不是从类中继承，而是在你的构造函数中接收它的抽象作为参数

3.3.2. 把你的组件看成相互拼接的乐高积木块，而不是对象的层次结构

3.3.3. 组合把共同的功能看成独立的组件

3.3.4. 组合更像是一种客户端-服务器的关系，而不是父-子关系

3.3.5. 通过它的引用来调用复用的代码，而不是在你的范围内继承它的方法

3.3.6. 把类作为参数进行接收还有一个额外的好处，那就是可以通过注入具体实现的模拟版本，让对象更加容易进行单元测试

3.3.7. 使用组合而不是继承可能需要你多写点代码

3.3.7.1. 因为你可能需要用接口而不是具体的引用来定义依赖关系，但这也会使代码摆脱依赖关系

4. 不要使用类

4.1. 类会产生少量的引用间接开销(reference indirection overhead)

4.1.1. 与值类型(value type)相比，它们更侧重间接方面

4.2. 值类型可以是有价值的

4.2.1. C#中的原始类型，如int、long和double，就是值类型

4.2.2. 可以用enum和struct这样的结构来组成你自己的值类型

4.3. enum用来保存离散的序数值(discrete ordinal value)是很不错的

4.3.1. 每一个你定义的enum的类型都是不同的，这让值拥有了类型安全(type-safe)

4.3.2. enum也是值类型，也就是说其值和整数值的传递速度是一样快的

4.4. 类会产生一点存储开销。每个类在实例化的时候都需要保留一个对象头和虚拟方法表

4.4.1. 类是在堆上分配的，而且它们会被回收

4.5. 结构是轻量级的类

4.5.1. 它们被分配在栈上，因为它们是值类型

4.5.2. 将一个结构值分配给一个变量意味着复制其内容，因为没有一个引用代表它

4.5.3. 对于任何大于指针大小的数据，复制的速度比仅传递引用的速度要慢

4.5.4. 因为结构是值类型，将它赋值给另一个结构时，会同时创建该结构所有内容的副本，而不仅仅是创建一个副本内容的引用

4.6. 在.NET中，栈的大小为1MB，而堆却可以包含TB级的数据

4.7. 栈的存取速度快，但是如果用大型结构去填充它，它很容易就被填满

4.8. 调用栈可以非常快速和有效地存储东西

4.8.1. 由于它们不受垃圾回收的影响，因此它们非常适用于处理较小的值，而且开销也较少

4.8.2. 因为它们不是引用类型，所以它们也不能为null，这使得结构不可能出现空引用异常

4.9. 你不能共享对它们的通用引用，这意味着你不能从不同的引用中更改通用实例

4.10. 当类较大时，可以提供更有效的存储，因为在赋值时只有它们的引用会被复制

4.11. 请放心地将结构用于不需要继承的小型、不可变的值类型

5. 糟糕代码

5.1. 最佳实践来自糟糕的代码，然而糟糕的代码也可能来自最佳实践的胡乱应用

5.2. 不要使用If/Else

5.2.1. If/Else让我们以一种类似于流程图的方式来表达程序的逻辑，但它也会使代码的可读性降低

5.2.2. 避免不必要缩进的一般原则是尽可能早地退出函数，并且在流程中已经暗示else语义时要避免使用else

5.2.3. “愉快路径”(happy path)

5.2.3.1. 没有其他错误发生时执行的代码部分

5.2.4. 通过将else语句转换为return语句，我们可以让读者更容易地识别愉快路径，而不是形成if语句的“俄罗斯套娃”

5.2.5. 尽早验证，并尽早返回

5.3. 使用goto

5.3.1. goto语句可以将程序的执行直接转移到一个任意的目标点

5.3.2. 许多现代编程语言不再有相当于goto语句的东西

5.3.3. C#有一个场景中非常有效：消除函数中多余的退出点

5.3.3.1. 退出点(exit point)是指函数中导致其返回给调用者的语句

5.3.3.2. 在C#中，每个返回语句都是一个退出点

5.3.3.3. 可以使用goto语句来清理，但实际上它在消除冗余方面更有优势

5.3.3.4. 如果你想在通用退出代码(common exit code)中增加更多的内容，你只需要把它添加到一个地方

5.3.3.4.1. 通过使用goto语句，我们实际上保持了代码的可读性，减少了缩进，节省了自己的时间，并使将来的修改更加容易，因为我们只需要修改一次

5.3.3.5. C# 7.0引入了局部函数，可以用来执行同样的工作，也许是以一种更容易理解的方式

5.3.3.6. 使用局部函数还允许我们在函数的顶部声明错误处理语句

6. 不写代码注释

6.1. 如果代码足够容易理解，则不需要编写代码注释

6.2. 使用那些无关的注释可能会毁掉代码的可读性

6.3. 若非必要，不写注释

6.4. 选个好名字

6.4.1. 使用HTTP、JSON、ID或者DB等广为人知的缩写倒还是可以的，但千万不要缩短单词

6.4.2. 当你选择一个描述性的名字时，你不必写一个完整的句子来解释它的功能

6.5. 充分利用函数

6.5.1. 短小的函数更易于理解

6.5.2. 尽量让函数尺寸适合开发人员的屏幕

6.5.2.1. 阅读代码时，来回滚动屏幕会让你不适，你应该一眼就能看到函数的全貌

6.5.3. 绝对不要把多个语句放在一行，一个语句至少得占用一行

6.6. 避免不必要的注释会使有用的注释像珍珠一样闪闪发光。这是使注释有用的唯一方法

6.7. 写了注释就能让你的代码很容易懂，前提是你的代码本身就精巧、易于理解

6.8. 公共API

6.8.1. 用户可能无法接触到代码

7. 要点

7.1. 避免因为混淆逻辑上的依赖界限而写出那些刚性代码

7.2. 不要害怕从头开始做一项工作，因为当你下次做的时候，你会发现进展要快得多

7.3. 请勇于拆分代码，并修整它

7.4. 保持代码最新并定期解决它所引起的问题

7.5. 重复代码而不是复用代码，避免混淆各代码逻辑的作用

7.6. 把抽象当作一项投资

7.6.1. 将抽象模型构思得巧妙一些，这样你将来写代码就会花更少的时间

7.7. 不要让使用的外部库来限制了你的设计

7.8. 为了避免将代码束缚在特定的层次结构，更推荐组合而不是继承

7.9. 尽量让代码保持自顶向下的风格，以便于阅读

7.10. 提前退出函数并避免使用else

7.10.1. return

7.11. 使用goto语句

7.11.1. 使用一个本地函数来将公共代码保存在一个地方

7.12. 避免随意、多余的注释

7.12.1. 只写有用的注释

7.13. 利用好变量和函数本身命名，让你写的代码更具可读性

7.14. 将函数划分为易于理解的子函数，以尽可能保持代码的可读性