diff --git a/notes/面向对象思想.md b/notes/面向对象思想.md index 1fea78ac..08299643 100644 --- a/notes/面向对象思想.md +++ b/notes/面向对象思想.md @@ -1,23 +1,23 @@ -* [设计原则](#设计原则) - * [1. S.O.L.I.D](#1-solid) - * [2. 其他常见原则](#2-其他常见原则) -* [三大特性](#三大特性) - * [1. 封装](#1-封装) - * [2. 继承](#2-继承) - * [3. 多态](#3-多态) -* [UML](#uml) - * [1. 类图](#1-类图) - * [2. 时序图](#2-时序图) +* [第一章 设计原则](#第一章-设计原则) + * [S.O.L.I.D](#solid) + * [其他常见原则](#其他常见原则) +* [第二章 三大特性](#第二章-三大特性) + * [封装](#封装) + * [继承](#继承) + * [多态](#多态) +* [第三章 UML](#第三章-uml) + * [类图](#类图) + * [时序图](#时序图) * [参考资料](#参考资料) -# 设计原则 +# 第一章 设计原则 设计原则可以帮助我们避免那些糟糕的设计，这些原则被归纳在《敏捷软件开发：原则、模式与实践》这本书中。 -## 1. S.O.L.I.D +## S.O.L.I.D | 简写 | 全拼 | 中文翻译 | | -- | -- | -- | @@ -27,7 +27,7 @@ | ISP | The Interface Segregation Principle | 接口分离原则 | | DIP | The Dependency Inversion Principle | 依赖倒置原则 | -### 1.1 单一责任原则 +### 1. 单一责任原则 **修改一个类的原因应该只有一个。** @@ -35,7 +35,7 @@ 如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱这个类完成其它职责的能力。 -### 1.2 开放封闭原则 +### 2. 开放封闭原则 **类应该对扩展开放，对修改关闭。** @@ -43,7 +43,7 @@ 符合开闭原则最典型的设计模式是装饰者模式，它可以动态地将责任附加到对象上，而不用去修改类的代码。 -### 1.3 里氏替换原则 +### 3. 里氏替换原则 **子类对象必须能够替换掉所有父类对象。** @@ -51,13 +51,13 @@ 如果不满足这个原则，那么各个子类的行为上就会有很大差异，增加继承体系的复杂度。 -### 1.4 接口分离原则 +### 4. 接口分离原则 **不应该强迫客户依赖于它们不用的方法。** 因此使用多个专门的接口比使用单一的总接口总要好。 -### 1.5 依赖倒置原则 +### 5. 依赖倒置原则 - **高层模块不应该依赖于低层模块，二者都应该依赖于抽象** - **抽象不应该依赖于细节，细节应该依赖于抽象** @@ -70,7 +70,7 @@ - 任何类都不应该从具体类派生； - 任何方法都不应该覆写它的任何基类中的已经实现的方法。 -## 2. 其他常见原则 +## 其他常见原则 除了上述的经典原则，在实际开发中还有下面这些常见的设计原则。 @@ -82,29 +82,29 @@ |SAP| The Stable Abstractions Principle | 稳定抽象原则 | |SDP| The Stable Dependencies Principle | 稳定依赖原则 | -### 2.1 迪米特法则 +### 1. 迪米特法则 迪米特法则又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。 -### 2.2 合成复用原则 +### 2. 合成复用原则 尽量使用对象组合，而不是继承来达到复用的目的。 -### 2.3 共同封闭原则 +### 3. 共同封闭原则 一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。 -### 2.4 稳定抽象原则 +### 4. 稳定抽象原则 最稳定的包应该是最抽象的包，不稳定的包应该是具体的包，即包的抽象程度跟它的稳定性成正比。 -### 2.5 稳定依赖原则 +### 5. 稳定依赖原则 包之间的依赖关系都应该是稳定方向依赖的，包要依赖的包要比自己更具有稳定性。 -# 三大特性 +# 第二章 三大特性 -## 1. 封装 +## 封装 利用抽象数据类型将数据和基于数据的操作封装在一起，使其构成一个不可分割的独立实体。数据被保护在抽象数据类型的内部，尽可能地隐藏内部的细节，只保留一些对外接口使之与外部发生联系。用户无需知道对象内部的细节，但可以通过对象对外提供的接口来访问该对象。 @@ -142,7 +142,7 @@ public class Person { } ``` -## 2. 继承 +## 继承 继承实现了 **IS-A** 关系，例如 Cat 和 Animal 就是一种 IS-A 关系，因此 Cat 可以继承自 Animal，从而获得 Animal 非 private 的属性和方法。 @@ -154,7 +154,7 @@ Animal animal = new Cat(); 继承应该遵循里氏替换原则，子类对象必须能够替换掉所有父类对象。 -## 3. 多态 +## 多态 多态分为编译时多态和运行时多态。编译时多态主要指方法的重载，运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定。 @@ -197,61 +197,61 @@ public class Music { } ``` -# UML +# 第三章 UML -## 1. 类图 +## 类图 -### 1.1 继承相关 +### 1. 继承相关 继承有两种形式 : 泛化（Generalize）和实现（Realize），表现为 IS-A 关系。 -**泛化关系 (Generalize)** +#### 泛化关系 (Generalize) 从具体类中继承。

-**实现关系 (Realize)** +#### 实现关系 (Realize) 从抽象类或者接口中继承。

-### 1.2 整体和部分 +### 2. 整体和部分 -**聚合关系 (Aggregation)** +#### 聚合关系 (Aggregation) 表示整体由部分组成，但是整体和部分不是强依赖的，整体不存在了部分还是会存在。以下表示 B 由 A 组成：

-**组合关系 (Composition)** +#### 组合关系 (Composition) 和聚合不同，组合中整体和部分是强依赖的，整体不存在了部分也不存在了。比如公司和部门，公司没了部门就不存在了。但是公司和员工就属于聚合关系了，因为公司没了员工还在。

-### 1.3 相互联系 +### 3. 相互联系 -**关联关系 (Association)** +#### 关联关系 (Association) 表示不同类对象之间有关联，这是一种静态关系，与运行过程的状态无关，在最开始就可以确定。因此也可以用 1 对 1、多对 1、多对多这种关联关系来表示。比如学生和学校就是一种关联关系，一个学校可以有很多学生，但是一个学生只属于一个学校，因此这是一种多对一的关系，在运行开始之前就可以确定。

-**依赖关系 (Dependency)** +#### 依赖关系 (Dependency) 和关联关系不同的是 , 依赖关系是在运行过程中起作用的。一般依赖作为类的构造器或者方法的参数传入。双向依赖时一种不好的设计。

-## 2. 时序图 +## 时序图 -### 2.1 定义 +### 1. 定义 时序图描述了对象之间传递消息的时间顺序，它用来表示用例的行为顺序。它的主要作用是通过对象间的交互来描述用例（注意是对象），从而寻找类的操作。 -### 2.2 赤壁之战时序图 +### 2. 赤壁之战时序图 从虚线从上往下表示时间的推进。 @@ -283,19 +283,19 @@ public class 孙权 { } ``` -### 2.3 活动图、时序图之间的关系 +### 3. 活动图、时序图之间的关系 活动图示从用户的角度来描述用例； 时序图是从计算机的角度（对象间的交互）描述用例。 -### 2.4 类图与时序图的关系 +### 4. 类图与时序图的关系 类图描述系统的静态结构，时序图描述系统的动态行为。 -### 2.5 时序图的组成 +### 5. 时序图的组成 -**对象** +#### 对象 有三种表现形式 @@ -307,13 +307,13 @@ public class 孙权 { 2. 把初始化整个交互活动的对象（有时是一个参与者）放置在最左边。 -**生命线** +#### 生命线 生命线从对象的创建开始到对象销毁时终止

-**消息** +#### 消息 对象之间的交互式通过发送消息来实现的。 @@ -333,7 +333,7 @@ public class 孙权 { 4\. 返回消息，可选。 -**激活** +#### 激活 生命线上的方框表示激活状态，其它时间处于休眠状态。