1.编程语言的实质

编程的目的是：用计算机来解决现实世界的问题。

编程的过程即：在计算机所能理解的 “模型” （解空间）和 现实世界 （问题空间）之间，建立一种联系。

编程语言是一种 “抽象” 的机制， 问题是对 “谁” 来抽象。

2.什么是抽象

抽象即从现实世界具体的问题域中提取出需要解决的关注点，以及各种概念之间的共性和关系，这样有助于我们用模型来描述解决方案，同时也有助于提升模型的可靠性和可复用性。

3.面向对象编程OOP

3.1什么是面向对象语言

第一个成功的面向对象的语言 Smalltalk 描述：

• 万物皆为对象

• 程序是对象的集合，它们通过发送消息来告知彼此所要做的。

• 每个对象都有自己的由其他对象所构成的存储。

• 每个对象都拥有其类型。

• 某一特定类型的所有对象都可以接收同样的消息。

C++ 和 Java 等后期的面向对象语言，都是在这个定义的基础上设计的。

3.2 面向对象的三大特性

封装

隐藏实现细节（访问控制）；定义接口；

继承

IS-A关系； HAS-A关系（组合）

多态

后期绑定（虚函数）；向上转型 （Up Casting）。面向对象的编程语言中，多态非常简单：子类实现父类或者接口的抽象方法，程序使用抽象父类或者接口编程，运行期注入不同的子类，程序就表现出不同的形态，是为多态。多态是面向对象语言最重要的特性，如果没有用好多态，那就是没有掌握好面向对象编程。

面向对象的三大特性其实是一脉相承的，先有封装，在封装的基础上才能实现继承，而有了来自于继承机制的基类和子类，才能实现多态。无论封装还是继承还是多态，其背后的思想精髓都是“抽象”。

代码的坏味道

面向对象编程思想最终的目的是为了实现高内聚、低耦合的程序，即相关的对象和逻辑尽可能封装在一起，而弱关联的、不同职责的部分则应当划分到不同的对象中，避免一段代码包含过多的内容，避免代码之间的调用关系过于复杂胶着。

软件设计的目的 坏味道的代码

如何避免写出坏味道的代码？Gang of Four（Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides）提出了三大类23种基本的设计模式。

SOLID原则

OOD 原则一：开/闭原则（OCP）

OCP － Open/Closed Principle

• 对于扩展是开放的（Open for extension）

• 对于更改是封闭的（Closed for modification）

• 简言之：不需要修改软件实体（类、模块、函数等），就应该能实现功能的扩展。

传统的扩展模块的方式就是修改模块的源代码。如何实现不修改而扩展呢？

• 关键是抽象！

OOD 原则二：依赖倒置原则（DIP）

DIP － Dependency Inversion Principle

• 高层模块不能依赖低层模块，而是大家都依赖于抽象；

• 抽象不能依赖实现，而是实现依赖抽象。

DIP 倒置了什么？

• 模块或包的依赖关系

• 开发顺序和职责

软件的层次化

• 高层决定低层

• 高层被重用

OOD 原则三：Liskov替换原则（LSP）

在 Java/C++ 这样的静态类型语言中，实现 OCP 的关键在于抽象，而抽象的威力在于多

态和继承。

• 一个正确的继承要符合什么要求呢？

• 答案：Liskov 替换原则

1988年，Barbara Liskov 描述这个原则：

• 若对每个类型 T1 的对象 o1，都存在一个类型 T2 的对象 o2，使得在所有针对 T2 编写的程序 P 中，用 o1 替换 o2 后，程序 P 的行为功能不变，则 T1 是 T2 的子类型。

• 简言之：子类型（subtype）必须能够替换掉它们的基类型（base type）。

LSP 要求，凡是使用基类的地方，一定也适用于其子类。

从 Java 语法角度看，意味着：

• 子类一定得拥有基类的整个接口。

• 子类的访问控制不能比基类更严格。 例如，Object 类中有一个方法：protected Object clone(); 子类中可以覆盖（override）之并放松其访问控制：public Object clone();但反过来是不行的，例如：覆盖 public String toString() 方法，并将其访问控制缩小成 private，编译器不可能允许这样的代码通过编译。

从更广泛的意义来看，子类的“契约”不能比基类更“严格”

• 例如，正方形长宽相等，这个契约比长方形要严格，因此正方形不是长方形的子类。

• 例如，Properties 的契约比 Hashtable 更严格。

单一职责原则

一个类只能有一个引起它变化的原因

所谓职责，就是引起变化的原因，单一职责原则避免了一个类过多的依赖，从而导致其本身的进化和复用困难重重，所有的分层架构都是在为实现单一职责提供帮助，因为不同关注点的发展方向、变化频率和目标都是不同的。但是在实践中，要完美符合单一职责原则并不是那么容易，例如MVC中的Controller作为Model和View之间的粘合层，往往就包含了各方面的对接和控制。不过，我们可以尽可能地将代码拆开成多个类，并以组合的形式进行程序构建。

接口隔离原则

不应强迫客户端依赖它不需要的方法

这是指导接口设计的原则，简单来说，这一原则跟单一职责原则的思想类似，提倡使用多个尽可能小的接口，而不是一个接口包含各种各样的方法，该否则当一个方法发生变化的时候，所有接口的使用方都需要跟着改变。