auto commit

notes/剑指 offer 题解.md

@@ -543,7 +543,11 @@ public int minNumberInRotateArray(int[] nums) {
 
 ## 题目描述
 
-请设计一个函数，用来判断在一个矩阵中是否存在一条包含某字符串所有字符的路径。路径可以从矩阵中的任意一个格子开始，每一步可以在矩阵中向左，向右，向上，向下移动一个格子。如果一条路径经过了矩阵中的某一个格子，则该路径不能再进入该格子。例如 a b c e s f c s a d e e 矩阵中包含一条字符串 "bcced" 的路径，但是矩阵中不包含 "abcb" 路径，因为字符串的第一个字符 b 占据了矩阵中的第一行第二个格子之后，路径不能再次进入该格子。
+请设计一个函数，用来判断在一个矩阵中是否存在一条包含某字符串所有字符的路径。路径可以从矩阵中的任意一个格子开始，每一步可以在矩阵中向左，向右，向上，向下移动一个格子。如果一条路径经过了矩阵中的某一个格子，则该路径不能再进入该格子。
+
+例如下面的矩阵包含了一条 bfce 路径。
+
+<div align="center"> <img src="../pics//e31abb94-9201-4e06-9902-61101b92f475.png" width="300"/> </div><br>
 
 ## 解题思路
 

notes/面向对象思想.md

@@ -1,125 +1,73 @@
 <!-- GFM-TOC -->
-* [一、设计原则](#一设计原则)
-    * [S.O.L.I.D](#solid)
-    * [其他常见原则](#其他常见原则)
-* [二、三大特性](#二三大特性)
-    * [封装](#封装)
-    * [继承](#继承)
-    * [多态](#多态)
-* [三、类图](#三类图)
-    * [泛化关系 (Generalization)](#泛化关系-generalization)
-    * [实现关系 (Realization)](#实现关系-realization)
-    * [聚合关系 (Aggregation)](#聚合关系-aggregation)
-    * [组合关系 (Composition)](#组合关系-composition)
-    * [关联关系 (Association)](#关联关系-association)
-    * [依赖关系 (Dependency)](#依赖关系-dependency)
+* [S.O.L.I.D](#solid)
+    * [1. 单一责任原则](#1-单一责任原则)
+    * [2. 开放封闭原则](#2-开放封闭原则)
+    * [3. 里氏替换原则](#3-里氏替换原则)
+    * [4. 接口分离原则](#4-接口分离原则)
+    * [5. 依赖倒置原则](#5-依赖倒置原则)
+* [封装、继承、多态](#封装继承多态)
+    * [1. 封装](#1-封装)
+    * [2. 继承](#2-继承)
+    * [3. 多态](#3-多态)
+* [UML](#uml)
+    * [1. 类图](#1-类图)
+    * [2. 时序图](#2-时序图)
 * [参考资料](#参考资料)
 <!-- GFM-TOC -->
 
 
-# 一、设计原则
+# S.O.L.I.D
 
-## 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. 单一责任原则
-
-> 修改一个类的原因应该只有一个。
-
-换句话说就是让一个类只负责一件事，当这个类需要做过多事情的时候，就需要分解这个类。
-
-如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱这个类完成其它职责的能力。
-
-### 2. 开放封闭原则
-
-> 类应该对扩展开放，对修改关闭。
-
-扩展就是添加新功能的意思，因此该原则要求在添加新功能时不需要修改代码。
-
-符合开闭原则最典型的设计模式是装饰者模式，它可以动态地将责任附加到对象上，而不用去修改类的代码。
-
-### 3. 里氏替换原则
-
-> 子类对象必须能够替换掉所有父类对象。
-
-继承是一种 IS-A 关系，子类需要能够当成父类来使用，并且需要比父类更特殊。
-
-如果不满足这个原则，那么各个子类的行为上就会有很大差异，增加继承体系的复杂度。
-
-### 4. 接口分离原则
-
-> 不应该强迫客户依赖于它们不用的方法。
-
-因此使用多个专门的接口比使用单一的总接口要好。
-
-### 5. 依赖倒置原则
-
-> 高层模块不应该依赖于低层模块，二者都应该依赖于抽象；</br>抽象不应该依赖于细节，细节应该依赖于抽象。
-
-高层模块包含一个应用程序中重要的策略选择和业务模块，如果高层模块依赖于低层模块，那么低层模块的改动就会直接影响到高层模块，从而迫使高层模块也需要改动。
-
-依赖于抽象意味着：
-
-- 任何变量都不应该持有一个指向具体类的指针或者引用；
-- 任何类都不应该从具体类派生；
-- 任何方法都不应该覆写它的任何基类中的已经实现的方法。
-
-## 其他常见原则
-
-除了上述的经典原则，在实际开发中还有下面这些常见的设计原则。
+S.O.L.I.D 是面向对象设计和编程 (OOD&OOP) 中几个重要编码原则 (Programming Priciple) 的首字母缩写。
 
 | 简写    | 全拼    | 中文翻译 |
-| :--: | :--: | :--: |
-|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    | 稳定依赖原则 |
+| -- | -- | -- |
+|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. 迪米特法则
 
-迪米特法则又叫作最少知识原则（Least Knowledge Principle，简写 LKP），就是说一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。
+## 1. 单一责任原则
 
-### 2. 合成复用原则
+当需要修改某个类的时候原因有且只有一个。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。
 
-尽量使用对象组合，而不是继承来达到复用的目的。
+## 2. 开放封闭原则
 
-### 3. 共同封闭原则
+软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。
 
-一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。
+## 3. 里氏替换原则
 
-### 4. 稳定抽象原则
+当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有 is-a 关系。
 
-最稳定的包应该是最抽象的包，不稳定的包应该是具体的包，即包的抽象程度跟它的稳定性成正比。
+## 4. 接口分离原则
 
-### 5. 稳定依赖原则
+不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。
 
-包之间的依赖关系都应该是稳定方向依赖的，包要依赖的包要比自己更具有稳定性。
+## 5. 依赖倒置原则
 
-# 二、三大特性
+1.  高层模块不应该依赖于低层模块，二者都应该依赖于抽象
+2.  抽象不应该依赖于细节，细节应该依赖于抽象
 
-## 封装
+# 封装、继承、多态
 
-利用抽象数据类型将数据和基于数据的操作封装在一起，使其构成一个不可分割的独立实体。数据被保护在抽象数据类型的内部，尽可能地隐藏内部的细节，只保留一些对外接口使之与外部发生联系。用户无需知道对象内部的细节，但可以通过对象对外提供的接口来访问该对象。
+封装、继承、多态是面向对象的三大特性。
+
+## 1. 封装
+
+利用抽象数据类型将数据和基于数据的操作封装在一起，使其构成一个不可分割的独立实体，数据被保护在抽象数据类型的内部，尽可能地隐藏内部的细节，只保留一些对外接口使之与外部发生联系。用户是无需知道对象内部的细节，但可以通过该对象对外的提供的接口来访问该对象。
 
 封装有三大好处：
 
-1. 减少耦合
-2. 隐藏内部细节，因此内部结构可以自由修改
-3. 可以对成员进行更精确的控制
+1. 良好的封装能够减少耦合。
+2. 类内部的结构可以自由修改。
+3. 可以对成员进行更精确的控制。
+4. 隐藏信息，实现细节。
 
 以下 Person 类封装 name、gender、age 等属性，外界只能通过 get() 方法获取一个 Person 对象的 name 属性和 gender 属性，而无法获取 age 属性，但是 age 属性可以供 work() 方法使用。
 
-注意到 gender 属性使用 int 数据类型进行存储，封装使得用户注意不到这种实现细节。并且在需要修改 gender 属性使用的数据类型时，也可以在不影响客户端代码的情况下进行。
+注意到 gender 属性使用 int 数据类型进行存储，封装使得用户注意不到这种实现细节。并且在需要修改使用的数据类型时，也可以在不影响客户端代码的情况下进行。
 
 ```java
 public class Person {
@@ -139,35 +87,31 @@ public class Person {
         if(18 <= age && age <= 50) {
             System.out.println(name + " is working very hard!");
         } else {
-            System.out.println(name + " can't work any more!");
+            System.out.println(name + " can't work!");
         }
     }
 }
 ```
 
-## 继承
+## 2. 继承
 
-继承实现了  **IS-A**  关系，例如 Cat 和 Animal 就是一种 IS-A 关系，因此 Cat 可以继承自 Animal，从而获得 Animal 非 private 的属性和方法。
+继承实现了  **is-a**  关系，例如 Cat 和 Animal 就是一种 is-a 关系，因此可以将 Cat 继承自 Animal，从而获得 Animal 非 private 的属性和方法。
 
-Cat 可以当做 Animal 来使用，也就是说可以使用 Animal 引用 Cat 对象。父类引用指向子类对象称为  **向上转型** 。
+Cat 可以当做 Animal 来使用，也就是可以使用 Animal 引用 Cat 对象，这种子类转换为父类称为  **向上转型** 。
+
+继承应该遵循里氏替换原则：当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有 is-a 关系。
 
 ```java
 Animal animal = new Cat();
 ```
 
-继承应该遵循里氏替换原则，子类对象必须能够替换掉所有父类对象。
+## 3. 多态
 
-## 多态
+多态分为编译时多态和运行时多态。编译时多态主要指方法的重装，运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定。
 
-多态分为编译时多态和运行时多态。编译时多态主要指方法的重载，运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定。
+多态有三个条件：1. 继承；2. 覆盖父类方法；3. 向上转型。
 
-运行时多态有三个条件：
-
-1. 继承
-2. 覆盖
-3. 向上转型
-
-下面的代码中，乐器类（Instrument）有两个子类：Wind 和 Percussion，它们都覆盖了父类的 play() 方法，并且在 main() 方法中使用父类 Instrument 来引用 Wind 和 Percussion 对象。在 Instrument 引用调用 play() 方法时，会执行实际引用对象所在类的 play() 方法，而不是 Instrument 类的方法。
+下面的代码中，乐器类（Instrument）有两个子类：Wind 和 Percussion，它们都覆盖了 play() 方法，并且在 main() 方法中使用父类 Instrument 来引用 Wind 和 Percussion 对象。在 Instrument 引用调用 play() 方法时，会执行实际引用对象所在类的 play() 方法，而不是 Instrument 类的方法。
 
 ```java
 public class Instrument {
@@ -198,55 +142,160 @@ public class Music {
         }
     }
 }
+
 ```
 
-# 三、类图
 
-## 泛化关系 (Generalization)
 
-用来描述继承关系，在 Java 中使用 extends 关键字。
+# UML
 
-<div align="center"> <img src="../pics//b418ca51-f005-4510-b7ad-f092eb6aeb24.png"/> </div><br>
+## 1. 类图
 
-## 实现关系 (Realization)
+**1.1 继承相关** 
 
-用来实现一个接口，在 Java 中使用 implement 关键字。
+继承有两种形式 : 泛化（generalize）和实现（realize），表现为 is-a 关系。
 
-<div align="center"> <img src="../pics//27cd6f0c-f581-45da-b8c9-fed026830560.png"/> </div><br>
+① 泛化关系 (generalization)
 
-## 聚合关系 (Aggregation)
+从具体类中继承
 
-表示整体由部分组成，但是整体和部分不是强依赖的，整体不存在了部分还是会存在。
+<div align="center"> <img src="../pics//29badd92-109f-4f29-abb9-9857f5973928.png"/> </div><br>
 
-<div align="center"> <img src="../pics//aa42f9c6-ad7a-48f4-8e8b-f3b6de3feaec.png"/> </div><br>
+② 实现关系 (realize)
 
-## 组合关系 (Composition)
+从抽象类或者接口中继承
+
+<div align="center"> <img src="../pics//4b16e1d3-3a60-472c-9756-2f31b1c48abe.png"/> </div><br>
+
+**1.2 整体和部分** 
+
+① 聚合关系 (aggregation)
+
+表示整体由部分组成，但是整体和部分不是强依赖的，整体不存在了部分还是会存在。以下表示 B 由 A 组成：
+
+<div align="center"> <img src="../pics//34259bb8-ca3a-4872-8771-9e946782d9c3.png"/> </div><br>
+
+② 组合关系 (composition)
 
 和聚合不同，组合中整体和部分是强依赖的，整体不存在了部分也不存在了。比如公司和部门，公司没了部门就不存在了。但是公司和员工就属于聚合关系了，因为公司没了员工还在。
 
-<div align="center"> <img src="../pics//0e34263d-7287-4ffe-a716-37c53d1a2526.png"/> </div><br>
+<div align="center"> <img src="../pics//7dda050d-ac35-4f47-9f51-18f18ed6fa9a.png"/> </div><br>
 
-## 关联关系 (Association)
+**1.3 相互联系** 
+
+① 关联关系 (association)
 
 表示不同类对象之间有关联，这是一种静态关系，与运行过程的状态无关，在最开始就可以确定。因此也可以用 1 对 1、多对 1、多对多这种关联关系来表示。比如学生和学校就是一种关联关系，一个学校可以有很多学生，但是一个学生只属于一个学校，因此这是一种多对一的关系，在运行开始之前就可以确定。
 
-<div align="center"> <img src="../pics//2017511e-22f0-4d74-873d-1261b71cf5a4.png"/> </div><br>
+<div align="center"> <img src="../pics//4ccd294c-d6b2-421b-839e-d88336ff5fb7.png"/> </div><br>
 
-## 依赖关系 (Dependency)
+② 依赖关系 (dependency)
 
-和关联关系不同的是，依赖关系是在运行过程中起作用的。A 类和 B 类是依赖关系主要有三种形式：
+和关联关系不同的是 , 依赖关系是在运行过程中起作用的。一般依赖作为类的构造器或者方法的参数传入。双向依赖时一种不好的设计。
 
-1. A 类是 B 类中的（某中方法的）局部变量；
-2. A 类是 B 类方法当中的一个参数；
-3. A 类向 B 类发送消息，从而影响 B 类发生变化；
+<div align="center"> <img src="../pics//47ca2614-509f-476e-98fc-50ec9f9d43c0.png"/> </div><br>
+
+## 2. 时序图
+
+http://www.cnblogs.com/wolf-sun/p/UML-Sequence-diagram.html
+
+**2.1 定义** 
+
+时序图描述了对象之间传递消息的时间顺序，它用来表示用例的行为顺序。它的主要作用是通过对象间的交互来描述用例（注意是对象），从而寻找类的操作。
+
+**2.2 赤壁之战时序图** 
+
+从虚线从上往下表示时间的推进。
+
+<div align="center"> <img src="../pics//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="../pics//25b8adad-2ef6-4f30-9012-c306b4e49897.png"/> </div><br>
+
+在画图时，应该遵循以下原则：
+
+1. 把交互频繁的对象尽可能地靠拢。
+
+2. 把初始化整个交互活动的对象（有时是一个参与者）放置在最左边。
+
+② 生命线
+
+生命线从对象的创建开始到对象销毁时终止
+
+<div align="center"> <img src="../pics//b7b0eac6-e7ea-4fb6-8bfb-95fec6f235e2.png"/> </div><br>
+
+③ 消息
+
+对象之间的交互式通过发送消息来实现的。
+
+消息有 4 种类型：
+
+1\. 简单消息，不区分同步异步。
+
+<div align="center"> <img src="../pics//a13b62da-0fa8-4224-a615-4cadacc08871.png"/> </div><br>
+
+2\. 同步消息，发送消息之后需要暂停活动来等待回应。
+
+<div align="center"> <img src="../pics//33821037-dc40-4266-901c-e5b38e618426.png"/> </div><br>
+
+3\. 异步消息，发送消息之后不需要等待。
+
+<div align="center"> <img src="../pics//dec6c6cc-1b5f-44ed-b8fd-464fcf849dac.png"/> </div><br>
+
+4\. 返回消息，可选。
+
+④ 激活
+
+生命线上的方框表示激活状态，其它时间处于休眠状态。
+
+<div align="center"> <img src="../pics//6ab5de9b-1c1e-4118-b2c3-fb6c7ed7de6f.png"/> </div><br>
 
-<div align="center"> <img src="../pics//c7d4956c-9988-4a10-a704-28fdae7f3d28.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)
+- [ 面向对象设计的 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)
+- [ 面向对象编程三大特性 ------ 封装、继承、多态 ](http://blog.csdn.net/jianyuerensheng/article/details/51602015)