视频学习：Bob Martin SOLID Principles of Object Oriented and Agile Design
Bob Martin SOLID Principles of Object Oriented and Agile Design
同事推荐的《clean code》，刚开始读，对于开发经验不足的我来说感觉还是太干，在网上搜了下Bob的演讲，收获挺大。建议把书和视频结合食用。
以下是一些学习笔记。
软件面临的问题
被“坏味道”的代码阻塞：程序员为了追求速度写下了坏的代码，但正“you want to go fast，you must go well”。
在面对任务时，应该有心脏手术师的样子。即使情况紧急，也应该一步一步慢条斯理的按照规程来，而不是毛毛躁躁，像下面Bob这样肯定是不行的。
坏代码的症状
复杂的依赖和耦合，Simple change breaks everything,导致到处跟踪Bug。最终项目经理会对code和coder失望，不再允许任何人修改后依赖这些代码。
如果个人代码，以不合适的方式依赖了其他代码，那么即使代码可以用，也将没有人敢复用
关于依赖
大部分的程序工作都是在管理依赖
以下是C语言的常见代码结构，具有树形依赖关系的函数调用。
顶层函数依赖了所有的下层函数，都是编译时依赖.
编译时依赖越多，每次修改部分代码时，需要重新编译的文件就越多。
违背了依赖倒置原则。通常高层概念和底层逻辑的耦合也使得代码难以理解。
关于OO
推销OOD的人会说：
- OO是对现实世界的建模，与我们的思考方式更接近。
Bob说：
- OO是选择性的抽象出接口，避免代码的过度耦合。
为什么要实现OOD
封装：
- C语言本身就是紧密封装的语言，编程人员在写C时，只能看到
函数签名， - OO中的public, protected 签名都破坏来封装。
"oo weakened encapsulation"
继承：
- C也能完成继承的逻辑，C++更方便，Java允许单继承，C#抄的Java，但继承不是OOD的主要目的，BOB只给了继承0.5分的重要性。
- 继承也不是实现多态的必要途径，c++可以通过函数指针实现。（虽然大部分情况是通过继承实现）。
多态
- 多态把编译时依赖，转化成了运行时依赖。
- M，N原本的编译时依赖，转化成了对稳定接口的依赖。
-
多态才是OO的重点，多态是继承的语法糖。 - 多态使得程序易懂，好复用，逻辑紧密。
SOLID 原则
SRP：单一责任（单一改变原则）
一个类，只可能出现一个更改需求。不出现3个产品经理让你同时改一个类的情况或者一个类不允许存在多口锅。
不要把多个可能改变的函数，放到同一个类里，他们很可能相互依赖，修改一个破坏另一个。
OCP： 开放封闭原则
在不改变一个类\接口的情况下，改变一个类\接口的行为。
对修改封闭，对扩展开放
一个失败的例子：
问题：
-
奇怪：读一个类时，需要了解所有类
- enum 耦合类所有类。
- switch耦合了所有类。
-
脆弱：
- 一些可能不是共有的方法，被强制耦合到了每个形状（面向过程，很容以写出这样的代码）
-
不易扩展：
- 不支持扩展需求，比如：分开编译，按图形收费的扩展模式。本质上因为过度耦合。
解决方法（谎言）：
- 如果添加一个椭圆形，完全不用重新编译。
- 但可能此时用户的需求是，不同图形按顺序展示。
- OOD要先设计出简单原型，然后搜集用户习惯，估计可能变化维度。
OOD是不断研究用户，研究变化的维度做设计
LSP：里氏替换原则
扩展类必须能从基类的接口，无障碍访问。
例子：正方形实现矩形接口
解决（谎言）：在setHeight的同时width也设置成同一值。
- 用户：Rectangle用户不知道setHeight时，width也发生了改变。然后一系列的问题就来类。
- 继承不是is-a，而是
"the redeclaration（？redecoration） of functions and variable in the subscope" - 在这里，正方形不能被矩形接口代替