视频学习：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"
• 在这里，正方形不能被矩形接口代替

ISP：接口分离原则

DIP：依赖道指原则