面向对象思想（CS-Notes）

客官°小女子只卖身不卖艺 2021-11-01 05:28 367阅读 0赞

**目录**

1 三大特性

1.1 封装

1.2 继承

1.3 多态

2 类图

2.1 泛化关系 (Generalization)

2.2 实现关系 (Realization)

2.3 聚合关系 (Aggregation)

2.4 组合关系 (Composition)

2.5 关联关系 (Association)

2.6 依赖关系 (Dependency)

3 设计原则

3.1 S.O.L.I.D

1. 单一责任原则

2. 开放封闭原则

3. 里氏替换原则

4. 接口分离原则

5. 依赖倒置原则

3.2 其他常见原则

1. 迪米特法则

2. 合成复用原则

3. 共同封闭原则

4. 稳定抽象原则

5. 稳定依赖原则

参考资料

--------------------

# 1 三大特性 #

## 1.1 封装 ##

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

优点：

*  **减少耦合**：可以独立地开发、测试、优化、使用、理解和修改
 *  减轻维护的负担：可以更容易被程序员理解，并且在调试的时候可以不影响其他模块
 *  有效地调节性能：可以通过剖析来确定哪些模块影响了系统的性能
 *  提高软件的可重用性
 *  降低了构建大型系统的风险：即使整个系统不可用，但是这些独立的模块却有可能是可用的

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

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

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!");
            }
        }
    }

## 1.2 继承 ##

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

> 继承应该遵循**里氏替换原则**，子类对象 必须能够替换掉 所有父类对象。
> 
> Cat 可以当做 Animal 来使用，也就是说**可以使用 Animal 引用 Cat 对象**。父类引用 指向 子类对象 称为 **向上转型** 。
> 
> 子类能当做父类来用

Animal animal = new Cat();

## 1.3 多态 ##

多态分为 **编译时多态** 和 **运行时多态**：

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

> 运行时多态有三个条件：
> 
>  *  继承
>  *  覆盖（重写）
>  *  向上转型

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

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();
            }
        }
    }

运行结果 ：

Wind is playing...
    Percussion is playing...

> 我的理解：
> 
> 父类 父类引用 = new 子类();
> 
> **父类引用**可以指向**子类对象**。但是拿这个**父类引用**去调用父类和子类中都有的方法时，会执行 **子类对象**的方法，而不是执行父类的方法。

--------------------

# 2 类图 #

以下类图使用 [PlantUML][] 绘制，更多语法及使用请参考：[http://plantuml.com/][http_plantuml.com] 。

## 2.1 泛化关系 (Generalization) ##

用来描述继承关系，在 Java 中使用 **extends** 关键字。

![aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tL2MwODc0ZTBhLWRiYTMtNDY3ZS05Yzg2LWRkOTMxM2UwODQzZS5qcGc][]

@startuml
    
    title Generalization
    
    class Vihical
    class Car
    class Trunck
    
    Vihical <|-- Car
    Vihical <|-- Trunck
    
    @enduml

## 2.2 实现关系 (Realization) ##

用来实现一个接口，在 Java 中使用 **implements** 关键字。

![aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tLzgzZDQ2NmJkLTk0NmItNDQzMC04NTRhLWNmN2IwNjk2ZDRjOC5qcGc][]

@startuml
    
    title Realization
    
    interface MoveBehavior
    class Fly
    class Run
    
    MoveBehavior <|.. Fly
    MoveBehavior <|.. Run
    
    @enduml

## 2.3 聚合关系 (Aggregation) ##

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

![aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tL2EwY2U0M2I3LWFmYTgtNDM5Ny1hOTZlLTVjMTJhMDcwZjJhZS5qcGc][]

@startuml
    
    title Aggregation
    
    class Computer
    class Keyboard
    class Mouse
    class Screen
    
    Computer o-- Keyboard
    Computer o-- Mouse
    Computer o-- Screen
    
    @enduml

## 2.4 组合关系 (Composition) ##

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

![aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tLzZhODhhMzk4LWM0OTQtNDFmNS1iYjYyLTlmN2ZiODExZGY3Yy5qcGc][]

@startuml
    
    title Composition
    
    class Company
    class DepartmentA
    class DepartmentB
    
    Company *-- DepartmentA
    Company *-- DepartmentB
    
    @enduml

## 2.5 关联关系 (Association) ##

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

![aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tL2EzZTRkYzYyLTBkYTUtNGQyMi05NGYyLTE0MDA3ODI4MTgxMi5qcGc][]

@startuml
    
    title Association
    
    class School
    class Student
    
    School "1" - "n" Student
    
    @enduml

## 2.6 依赖关系 (Dependency) ##

> 假设A类的变化引起了B类的变化，则B类依赖于A类。

和关联关系不同的是，依赖关系是在运行过程中起作用的。A 类和 B 类是依赖关系主要有三种形式：

*  A 类 是 **B 类方法的局部变量**；
 *  A 类 是 **B 类方法当中的一个参数**；
 *  A 类 向 B 类发送消息，从而影响 B 类发生变化。

![aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tLzM3OTQ0NGM5LWYxZDEtNDVjZC1iN2FhLWIwYzE4NDI3ZDM4OC5qcGc][]

@startuml
    
    title Dependency
    
    class Vihicle {
        move(MoveBehavior)
    }
    
    interface MoveBehavior {
        move()
    }
    
    note "MoveBehavior.move()" as N
    
    Vihicle ..> MoveBehavior
    
    Vihicle .. N
    
    @enduml

> 扩展学习：[https://blog.csdn.net/wang15061955806/article/details/50551385][https_blog.csdn.net_wang15061955806_article_details_50551385]

--------------------

# 3 设计原则 #

## 3.1 S.O.L.I.D ##

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

### 1. 单一责任原则 ###

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

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

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

### 2. 开放封闭原则 ###

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

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

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

### 3. 里氏替换原则 ###

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

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

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

### 4. 接口分离原则 ###

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

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

### 5. 依赖倒置原则 ###

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

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

> **依赖于 抽象**，意味着：
> 
>  *  任何变量 都**不应该持有** 一个指向具体类的指针或者引用；
>  *  任何类 都**不应该从**具体类**派生**；
>  *  任何方法 都**不应该覆写** 它的任何基类中的已经实现的方法。

## 3.2 其他常见原则 ##

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

<table> 
 <thead> 
  <tr> 
   <th>简写</th> 
   <th>全拼</th> 
   <th>中文翻译</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>LOD</td> 
   <td>The Law of Demeter</td> 
   <td>迪米特法则</td> 
  </tr> 
  <tr> 
   <td>CRP</td> 
   <td>The Composite Reuse Principle</td> 
   <td>合成复用原则</td> 
  </tr> 
  <tr> 
   <td>CCP</td> 
   <td>The Common Closure Principle</td> 
   <td>共同封闭原则</td> 
  </tr> 
  <tr> 
   <td>SAP</td> 
   <td>The Stable Abstractions Principle</td> 
   <td>稳定抽象原则</td> 
  </tr> 
  <tr> 
   <td>SDP</td> 
   <td>The Stable Dependencies Principle</td> 
   <td>稳定依赖原则</td> 
  </tr> 
 </tbody> 
</table>

### 1. 迪米特法则 ###

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

### 2. 合成复用原则 ###

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

### 3. 共同封闭原则 ###

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

### 4. 稳定抽象原则 ###

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

### 5. 稳定依赖原则 ###

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

> A包 应该依赖 比A包更稳定的B包

--------------------

# 参考资料 #

*  Java 编程思想
 *  敏捷软件开发：原则、模式与实践
 *  [面向对象设计的 SOLID 原则][SOLID]
 *  [看懂 UML 类图和时序图][UML]
 *  [UML 系列——时序图（顺序图）sequence diagram][UML _sequence diagram]
 *  [面向对象编程三大特性 ------ 封装、继承、多态][------]

[PlantUML]: https://www.planttext.com/
[http_plantuml.com]: http://plantuml.com/
[aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tL2MwODc0ZTBhLWRiYTMtNDY3ZS05Yzg2LWRkOTMxM2UwODQzZS5qcGc]: /images/20211101/8d6b179443054752b89c456527d846b3.png
[aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tLzgzZDQ2NmJkLTk0NmItNDQzMC04NTRhLWNmN2IwNjk2ZDRjOC5qcGc]: /images/20211101/7d7c6e94ff8a44f683a632c729b9f36a.png
[aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tL2EwY2U0M2I3LWFmYTgtNDM5Ny1hOTZlLTVjMTJhMDcwZjJhZS5qcGc]: /images/20211101/9ab221a923494e08a35d363715ae1374.png
[aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tLzZhODhhMzk4LWM0OTQtNDFmNS1iYjYyLTlmN2ZiODExZGY3Yy5qcGc]: /images/20211101/5c4534486c464c53909333555e016909.png
[aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tL2EzZTRkYzYyLTBkYTUtNGQyMi05NGYyLTE0MDA3ODI4MTgxMi5qcGc]: /images/20211101/70cb8281b089444383a8a2076d3de796.png
[aHR0cHM6Ly9jcy1ub3Rlcy0xMjU2MTA5Nzk2LmNvcy5hcC1ndWFuZ3pob3UubXlxY2xvdWQuY29tLzM3OTQ0NGM5LWYxZDEtNDVjZC1iN2FhLWIwYzE4NDI3ZDM4OC5qcGc]: /images/20211101/3670bedcc7ea4b6fa2287f3418fea593.png
[https_blog.csdn.net_wang15061955806_article_details_50551385]: https://blog.csdn.net/wang15061955806/article/details/50551385
[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