CS-Notes/notes/面向对象思想.md

<!-- GFM-TOC -->
* [设计原则](#设计原则)
    * [1. S.O.L.I.D](#1-solid)
        * [1.1 单一责任原则](#11-单一责任原则)
        * [1.2 开放封闭原则](#12-开放封闭原则)
        * [1.3 里氏替换原则](#13-里氏替换原则)
        * [1.4 接口分离原则](#14-接口分离原则)
        * [1.5 依赖倒置原则](#15-依赖倒置原则)
    * [2. 其他常见原则](#2-其他常见原则)
        * [2.1 迪米特法则](#21-迪米特法则)
        * [2.2 合成复用原则](#22-合成复用原则)
        * [2.3 共同封闭原则](#23-共同封闭原则)
        * [2.4 稳定抽象原则](#24-稳定抽象原则)
        * [2.5 稳定依赖原则](#25-稳定依赖原则)
* [三大特性](#三大特性)
    * [1. 封装](#1-封装)
    * [2. 继承](#2-继承)
    * [3. 多态](#3-多态)
* [UML](#uml)
    * [1. 类图](#1-类图)
        * [1.1 继承相关](#11-继承相关)
        * [1.2 整体和部分](#12-整体和部分)
        * [1.3 相互联系](#13-相互联系)
    * [2. 时序图](#2-时序图)
        * [2.1 定义](#21-定义)
        * [2.2 赤壁之战时序图](#22-赤壁之战时序图)
        * [2.3 活动图、时序图之间的关系](#23-活动图时序图之间的关系)
        * [2.4 类图与时序图的关系](#24-类图与时序图的关系)
        * [2.5 时序图的组成](#25-时序图的组成)
* [参考资料](#参考资料)
<!-- GFM-TOC -->


# 设计原则

设计原则可以帮助我们避免那些糟糕的设计，这些原则被归纳在《敏捷软件开发：原则、模式与实践》这本书中。

## 1. S.O.L.I.D

| 简写 | 全拼 | 中文翻译 |
| -- | -- | -- |
| SRP | The Single Responsibility Principle    | 单一责任原则 |
| OCP | The Open Closed Principle              | 开放封闭原则 |
| LSP | The Liskov Substitution Principle      | 里氏替换原则 |
| ISP | The Interface Segregation Principle    | 接口分离原则 |
| DIP | The Dependency Inversion Principle     | 依赖倒置原则 |

### 1.1 单一责任原则

**修改一个类的原因应该只有一个。** 

换句话说就是让一个类只负责一件事，当这个类需要做过多事情的时候，就需要分解这个类。

如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱这个类完成其它职责的能力。

### 1.2 开放封闭原则

**类应该对扩展开放，对修改关闭。** 

扩展就是添加新功能的意思，因此该原则要求在添加新功能时不需要修改代码。

符合开闭原则最典型的设计模式是装饰者模式，它可以动态地将责任附加到对象上，而不用去修改类的代码。

### 1.3 里氏替换原则

**子类对象必须能够替换掉所有父类对象。** 

继承是一种 IS-A 关系，子类需要能够当成父类来使用，并且需要比父类更特殊。

如果不满足这个原则，那么各个子类的行为上就会有很大差异，增加继承体系的复杂度。

### 1.4 接口分离原则

**不应该强迫客户依赖于它们不用的方法。** 

因此使用多个专门的接口比使用单一的总接口总要好。

### 1.5 依赖倒置原则

-  **高层模块不应该依赖于低层模块，二者都应该依赖于抽象** 
-  **抽象不应该依赖于细节，细节应该依赖于抽象** 

高层模块包含一个应用程序中重要的策略选择和业务模块，如果高层模块依赖于底层模块，那么底层模块的改动就会直接影响到高层模块，从而迫使高层模块也需要改动。

依赖于抽象意味着：

- 任何变量都不应该持有一个指向具体类的指针或者引用；
- 任何类都不应该从具体类派生；
- 任何方法都不应该覆写它的任何基类中的已经实现的方法。

## 2. 其他常见原则

除了上述的经典原则，在实际开发中还有下面这些常见的设计原则。

| 简写    | 全拼    | 中文翻译 |
| -- | -- | -- |
|LoD|    The Law of Demeter                   | 迪米特法则   |
|CRP|    The Composite Reuse Principle        | 合成复用原则 |
|CCP|    The Common Closure Principle         | 共同封闭原则 |
|SAP|    The Stable Abstractions Principle    | 稳定抽象原则 |
|SDP|    The Stable Dependencies Principle    | 稳定依赖原则 |

### 2.1 迪米特法则

迪米特法则又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。

### 2.2 合成复用原则

尽量使用对象组合，而不是继承来达到复用的目的。

### 2.3 共同封闭原则

一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。

### 2.4 稳定抽象原则

最稳定的包应该是最抽象的包，不稳定的包应该是具体的包，即包的抽象程度跟它的稳定性成正比。

### 2.5 稳定依赖原则

包之间的依赖关系都应该是稳定方向依赖的，包要依赖的包要比自己更具有稳定性。

# 三大特性

## 1. 封装

利用抽象数据类型将数据和基于数据的操作封装在一起，使其构成一个不可分割的独立实体。数据被保护在抽象数据类型的内部，尽可能地隐藏内部的细节，只保留一些对外接口使之与外部发生联系。用户无需知道对象内部的细节，但可以通过对象对外提供的接口来访问该对象。

封装有三大好处：

1. 减少耦合
2. 隐藏内部细节，因此内部结构可以自由修改
3. 可以对成员进行更精确的控制

以下 Person 类封装 name、gender、age 等属性，外界只能通过 get() 方法获取一个 Person 对象的 name 属性和 gender 属性，而无法获取 age 属性，但是 age 属性可以供 work() 方法使用。

注意到 gender 属性使用 int 数据类型进行存储，封装使得用户注意不到这种实现细节。并且在需要修改 gender 属性使用的数据类型时，也可以在不影响客户端代码的情况下进行。

```java
public class Person {
    private String name;
    private int gender;
    private int age;

    public String getName() {
        return name;
    }

    public String getGender() {
        return gender == 0 ? "man" : "woman";
    }

    public void work() {
        if(18 <= age && age <= 50) {
            System.out.println(name + " is working very hard!");
        } else {
            System.out.println(name + " can't work any more!");
        }
    }
}
```

## 2. 继承

继承实现了  **IS-A**  关系，例如 Cat 和 Animal 就是一种 IS-A 关系，因此 Cat 可以继承自 Animal，从而获得 Animal 非 private 的属性和方法。

Cat 可以当做 Animal 来使用，也就是说可以使用 Animal 引用 Cat 对象。父类引用指向子类对象称为  **向上转型** 。

```java
Animal animal = new Cat();
```

继承应该遵循里氏替换原则，子类对象必须能够替换掉所有父类对象。

## 3. 多态

多态分为编译时多态和运行时多态。编译时多态主要指方法的重载，运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定。

运行时多态有三个条件：

1. 继承
2. 覆盖
3. 向上转型

下面的代码中，乐器类（Instrument）有两个子类：Wind 和 Percussion，它们都覆盖了父类的 play() 方法，并且在 main() 方法中使用父类 Instrument 来引用 Wind 和 Percussion 对象。在 Instrument 引用调用 play() 方法时，会执行实际引用对象所在类的 play() 方法，而不是 Instrument 类的方法。

```java
public class Instrument {
    public void play() {
        System.out.println("Instument is playing...");
    }
}

public class Wind extends Instrument {
    public void play() {
        System.out.println("Wind is playing...");
    }
}

public class Percussion extends Instrument {
    public void play() {
        System.out.println("Percussion is playing...");
    }
}

public class Music {
    public static void main(String[] args) {
        List<Instrument> instruments = new ArrayList<>();
        instruments.add(new Wind());
        instruments.add(new Percussion());
        for(Instrument instrument : instruments) {
            instrument.play();
        }
    }
}
```

# UML

## 1. 类图

### 1.1 继承相关

继承有两种形式 : 泛化（Generalize）和实现（Realize），表现为 IS-A 关系。

**泛化关系 (Generalize)** 

从具体类中继承。

<div align="center"> <img src="index_files/29badd92-109f-4f29-abb9-9857f5973928.png"/> </div><br>

**实现关系 (Realize)** 

从抽象类或者接口中继承。

<div align="center"> <img src="index_files/4b16e1d3-3a60-472c-9756-2f31b1c48abe.png"/> </div><br>

### 1.2 整体和部分

**聚合关系 (Aggregation)** 

表示整体由部分组成，但是整体和部分不是强依赖的，整体不存在了部分还是会存在。以下表示 B 由 A 组成：

<div align="center"> <img src="index_files/34259bb8-ca3a-4872-8771-9e946782d9c3.png"/> </div><br>

**组合关系 (Composition)** 

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

<div align="center"> <img src="index_files/7dda050d-ac35-4f47-9f51-18f18ed6fa9a.png"/> </div><br>

### 1.3 相互联系

**关联关系 (Association)** 

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

<div align="center"> <img src="index_files/4ccd294c-d6b2-421b-839e-d88336ff5fb7.png"/> </div><br>

**依赖关系 (Dependency)** 

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

<div align="center"> <img src="index_files/47ca2614-509f-476e-98fc-50ec9f9d43c0.png"/> </div><br>

## 2. 时序图

### 2.1 定义

时序图描述了对象之间传递消息的时间顺序，它用来表示用例的行为顺序。它的主要作用是通过对象间的交互来描述用例（注意是对象），从而寻找类的操作。

### 2.2 赤壁之战时序图

从虚线从上往下表示时间的推进。

<div align="center"> <img src="index_files/80c5aff8-fc46-4810-aeaa-215b5c60a003.png"/> </div><br>

可见，通过时序图可以知道每个类具有以下操作：

```java
publc class 刘备 {
   public void 应战 ();
}

publc class  孔明 {
  public void  拟定策略 ();
  public void  联合孙权 ();
  private void 借东风火攻 ();
}

public class 关羽 {
    public void  防守荊州 ();
}

public class 张飞 {
   public void  防守荆州前线 ();
}

public class 孙权 {
   public void  领兵相助 ();
}
```

### 2.3 活动图、时序图之间的关系

活动图示从用户的角度来描述用例；

时序图是从计算机的角度（对象间的交互）描述用例。

### 2.4 类图与时序图的关系

类图描述系统的静态结构，时序图描述系统的动态行为。

### 2.5 时序图的组成

**对象** 

有三种表现形式

<div align="center"> <img src="index_files/25b8adad-2ef6-4f30-9012-c306b4e49897.png"/> </div><br>

在画图时，应该遵循以下原则：

1. 把交互频繁的对象尽可能地靠拢。

2. 把初始化整个交互活动的对象（有时是一个参与者）放置在最左边。

**生命线** 

生命线从对象的创建开始到对象销毁时终止

<div align="center"> <img src="index_files/b7b0eac6-e7ea-4fb6-8bfb-95fec6f235e2.png"/> </div><br>

**消息** 

对象之间的交互式通过发送消息来实现的。

消息有 4 种类型：

1\. 简单消息，不区分同步异步。

<div align="center"> <img src="index_files/a13b62da-0fa8-4224-a615-4cadacc08871.png"/> </div><br>

2\. 同步消息，发送消息之后需要暂停活动来等待回应。

<div align="center"> <img src="index_files/33821037-dc40-4266-901c-e5b38e618426.png"/> </div><br>

3\. 异步消息，发送消息之后不需要等待。

<div align="center"> <img src="index_files/dec6c6cc-1b5f-44ed-b8fd-464fcf849dac.png"/> </div><br>

4\. 返回消息，可选。

**激活** 

生命线上的方框表示激活状态，其它时间处于休眠状态。

<div align="center"> <img src="index_files/6ab5de9b-1c1e-4118-b2c3-fb6c7ed7de6f.png"/> </div><br>

# 参考资料

- Java 编程思想
- 敏捷软件开发：原则、模式与实践
- [面向对象设计的 SOLID 原则](http://www.cnblogs.com/shanyou/archive/2009/09/21/1570716.html)
- [看懂 UML 类图和时序图](http://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html#generalization)
- [UML 系列——时序图（顺序图）sequence diagram](http://www.cnblogs.com/wolf-sun/p/UML-Sequence-diagram.html)
- [面向对象编程三大特性 ------ 封装、继承、多态](http://blog.csdn.net/jianyuerensheng/article/details/51602015)