auto commit

This commit is contained in:
CyC2018
2018-03-06 11:17:27 +08:00
parent 65fe30f23f
commit 5608f55f36
18 changed files with 546 additions and 546 deletions

View File

@ -36,47 +36,47 @@
# 第一章 设计模式入门
**1. 设计模式概念**
**1. 设计模式概念**
设计模式不是代码,而是解决问题的方案,学习现有的设计模式可以做到经验复用。
拥有设计模式词汇,在沟通时就能用更少的词汇来讨论,并且不需要了解底层细节。
**2. 问题描述**
**2. 问题描述**
设计不同种类的鸭子拥有不同的叫声和飞行方式。
**3. 简单实现方案**
**3. 简单实现方案**
使用继承的解决方案如下,这种方案代码无法复用,如果两个鸭子类拥有同样的飞行方式,就有两份重复的代码。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//144d28a0-1dc5-4aba-8961-ced5bc88428a.jpg"/> </div><br>
**4. 设计原则**
**4. 设计原则**
**封装变化**在这里变化的是鸭子叫和飞行的行为方式。
**封装变化** 在这里变化的是鸭子叫和飞行的行为方式。
**针对接口编程,而不是针对实现编程** 变量声明的类型为父类,而不是具体的某个子类。父类中的方法实现不在父类,而是在各个子类。程序在运行时可以动态改变变量所指向的子类类型。
**针对接口编程,而不是针对实现编程** 变量声明的类型为父类,而不是具体的某个子类。父类中的方法实现不在父类,而是在各个子类。程序在运行时可以动态改变变量所指向的子类类型。
运用这一原则,将叫和飞行的行为抽象出来,实现多种不同的叫和飞行的子类,让子类去实现具体的叫和飞行方式。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//1c8ccf5c-7ecd-4b8a-b160-3f72a510ce26.png"/> </div><br>
**多用组合,少用继承** 组合也就是 has-a 关系,通过组合,可以在运行时动态改变实现,只要通过改变父类对象具体指向哪个子类即可。而继承就不能做到这些,继承体系在创建类时就已经确定。
**多用组合,少用继承** 组合也就是 has-a 关系,通过组合,可以在运行时动态改变实现,只要通过改变父类对象具体指向哪个子类即可。而继承就不能做到这些,继承体系在创建类时就已经确定。
运用这一原则,在 Duck 类中组合 FlyBehavior 和 QuackBehavior 类performQuack() 和 performFly() 方法委托给这两个类去处理。通过这种方式,一个 Duck 子类可以根据需要去实例化 FlyBehavior 和 QuackBehavior 的子类对象,并且也可以动态地进行改变。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//29574e6f-295c-444e-83c7-b162e8a73a83.jpg"/> </div><br>
**5. 整体设计图**
**5. 整体设计图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//e13833c8-e215-462e-855c-1d362bb8d4a0.jpg"/> </div><br>
**6. 模式定义**
**6. 模式定义**
**策略模式** :定义了算法族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
**策略模式** :定义了算法族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
**7. 实现代码**
**7. 实现代码**
```java
public abstract class Duck {
@ -181,13 +181,13 @@ FlyBehavior.FlyNoWay
# 第二章 观察者模式
**1. 模式定义**
**1. 模式定义**
定义了对象之间的一对多依赖当一个对象改变状态时它的所有依赖者都会受到通知并自动更新。主题Subject是被观察的对象而其所有依赖者Observer成为观察者。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//26cb5e7e-6fa3-44ad-854e-fe24d1a5278c.jpg"/> </div><br>
**2. 模式类图**
**2. 模式类图**
主题中具有注册和移除观察者,并通知所有注册者的功能,主题是通过维护一张观察者列表来实现这些操作的。
@ -195,19 +195,19 @@ FlyBehavior.FlyNoWay
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//5c558190-fccd-4b5e-98ed-1896653fc97f.jpg"/> </div><br>
**3. 问题描述**
**3. 问题描述**
天气数据布告板会在天气信息发生改变时更新其内容,布告板有多个,并且在将来会继续增加。
**4. 解决方案类图**
**4. 解决方案类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//760a5d63-d96d-4dd9-bf9a-c3d126b2f401.jpg"/> </div><br>
**5. 设计原则**
**5. 设计原则**
**为交互对象之间的松耦合设计而努力** 当两个对象之间松耦合,它们依然可以交互,但是不太清楚彼此的细节。由于松耦合的两个对象之间互相依赖程度很低,因此系统具有弹性,能够应对变化。
**为交互对象之间的松耦合设计而努力** 当两个对象之间松耦合,它们依然可以交互,但是不太清楚彼此的细节。由于松耦合的两个对象之间互相依赖程度很低,因此系统具有弹性,能够应对变化。
**6. 实现代码**
**6. 实现代码**
```java
public interface Subject {
@ -315,11 +315,11 @@ StatisticsDisplay.update:1.0 1.0 1.0
# 第三章 装饰模式
**1. 问题描述**
**1. 问题描述**
设计不同种类的饮料,并且每种饮料可以动态添加新的材料,比如可以添加牛奶。计算一种饮料的价格。
**2. 模式定义**
**2. 模式定义**
动态地将责任附加到对象上。在扩展功能上,装饰者提供了比继承更有弹性的替代方案。
@ -327,25 +327,25 @@ StatisticsDisplay.update:1.0 1.0 1.0
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//41a4cb30-f393-4b3b-abe4-9941ccf8fa1f.jpg"/> </div><br>
**3. 模式类图**
**3. 模式类图**
装饰者和具体组件都继承自组件类型,其中具体组件的方法实现不需要依赖于其它对象,而装饰者拥有一个组件类型对象,这样它可以装饰其它装饰者或者具体组件。所谓装饰,就是把这个装饰者套在被装饰的对象之外,从而动态扩展被装饰者的功能。装饰者的方法有一部分是自己的,这属于它的功能,然后调用被装饰者的方法实现,从而也保留了被装饰者的功能。可以看到,具体组件应当是装饰层次的最低层,因为只有具体组件有直接实现而不需要委托给其它对象去处理。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//3dc454fb-efd4-4eb8-afde-785b2182caeb.jpg"/> </div><br>
**4. 问题解决方案的类图**
**4. 问题解决方案的类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//9c997ac5-c8a7-44fe-bf45-2c10eb773e53.jpg"/> </div><br>
**5. 设计原则**
**5. 设计原则**
**类应该对扩展开放,对修改关闭。** 也就是添加新功能时不需要修改代码。在本章问题中该原则体现在,在饮料中添加新的材料,而不需要去修改饮料的代码。观察则模式也符合这个原则。不可能所有类都能实现这个原则,应当把该原则应用于设计中最有可能改变的地方。
**类应该对扩展开放,对修改关闭。** 也就是添加新功能时不需要修改代码。在本章问题中该原则体现在,在饮料中添加新的材料,而不需要去修改饮料的代码。观察则模式也符合这个原则。不可能所有类都能实现这个原则,应当把该原则应用于设计中最有可能改变的地方。
**6. Java I/O 中的装饰者模式**
**6. Java I/O 中的装饰者模式**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//2a40042a-03c8-4556-ad1f-72d89f8c555c.jpg"/> </div><br>
**7. 代码实现**
**7. 代码实现**
```java
public interface Beverage {
@ -420,22 +420,22 @@ public class StartbuzzCoffee {
## 1. 简单工厂
**1. 问题描述**
**1. 问题描述**
有不同的 Pizza根据不同的情况用不同的子类实例化一个 Pizza 对象。
**2. 定义**
**2. 定义**
简单工厂不是设计模式,更像是一种编程习惯。在实例化一个超类的对象时,可以用它的所有子类来进行实例化,要根据具体需求来决定使用哪个子类。在这种情况下,把实例化的操作放到工厂来中,让工厂类来决定应该用哪个子类来实例化。这样做把客户对象和具体子类的实现解耦,客户对象不再需要知道有哪些子类以及实例化哪个子类。因为客户类往往有多个,如果不使用简单工厂,那么所有的客户类都要知道所有子类的细节,一旦子类发生改变,例如增加子类,那么所有的客户类都要发生改变。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//c470eb9b-fb05-45c5-8bb7-1057dc3c16de.jpg"/> </div><br>
**3. 解决方案类图**
**3. 解决方案类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//dc3e704c-7c57-42b8-93ea-ddd068665964.jpg"/> </div><br>
**4. 代码实现**
**4. 代码实现**
```java
public interface Pizza {
@ -489,15 +489,15 @@ CheesePizza
## 2. 工厂方法模式
**1. 问题描述**
**1. 问题描述**
每个地区的 Pizza 店虽然种类相同,但是都有自己的风味,需要单独区分。例如,一个客户点了纽约的 cheese 种类的 Pizza 和在芝加哥点的相同种类的 Pizza 是不同的。
**2. 模式定义**
**2. 模式定义**
定义了一个创建对象的接口,但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
**3. 模式类图**
**3. 模式类图**
在简单工厂中创建对象的是另一个类而在工厂方法中是由子类来创建对象。下图中Creator 有一个 anOperation() 方法,这个方法需要用到一组产品类,这组产品类由每个子类来创建。
@ -505,11 +505,11 @@ CheesePizza
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//903093ec-acc8-4f9b-bf2c-b990b9a5390c.jpg"/> </div><br>
**4. 解决方案类图**
**4. 解决方案类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//664f8901-5dc7-4644-a072-dad88cc5133a.jpg"/> </div><br>
**5. 代码实现**
**5. 代码实现**
```java
public interface Pizza {
@ -607,27 +607,27 @@ ChicagoStyleCheesePizza is making..
## 3. 抽象工厂模式
**1. 设计原则**
**1. 设计原则**
**依赖倒置原则**:要依赖抽象,不要依赖具体类。听起来像是针对接口编程,不针对实现编程,但是这个原则说明了:不能让高层组件依赖底层组件,而且,不管高层或底层组件,两者都应该依赖于抽象。例如,下图中 PizzaStore 属于高层组件,它依赖的是 Pizza 的抽象类,这样就可以不用关心 Pizza 的具体实现细节。
**依赖倒置原则** :要依赖抽象,不要依赖具体类。听起来像是针对接口编程,不针对实现编程,但是这个原则说明了:不能让高层组件依赖底层组件,而且,不管高层或底层组件,两者都应该依赖于抽象。例如,下图中 PizzaStore 属于高层组件,它依赖的是 Pizza 的抽象类,这样就可以不用关心 Pizza 的具体实现细节。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//ddf72ca9-c0be-49d7-ab81-57a99a974c8e.jpg"/> </div><br>
**2. 模式定义**
**2. 模式定义**
提供一个接口,用于创建相关或依赖对象的家族,而不需要明确指定具体类。
**3. 模式类图**
**3. 模式类图**
抽象工厂模式创建的是对象家族也就是很多对象而不是一个对象并且这些对象是相关的也就是说必须一起创建出来。而工厂模式只是用于创建一个对象这和抽象工厂模式有很大不同。并且抽象工厂模式也用到了工厂模式来创建单一对象在类图左部AbstractFactory 中的 CreateProductA 和 CreateProductB 方法都是让子类来实现,这两个方法单独来看就是在创建一个对象,这符合工厂模式的定义。至于创建对象的家族这一概念是在 Client 体现Client 要通过 AbstractFactory 同时调用两个方法来创建出两个对象在这里这两个对象就有很大的相关性Client 需要这两个对象的协作才能完成任务。从高层次来看,抽象工厂使用了组合,即 Cilent 组合了 AbstractFactory ,而工厂模式使用了继承。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//d301774f-e0d2-41f3-95f4-bfe39859b52e.jpg"/> </div><br>
**4. 解决方案类图**
**4. 解决方案类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//8785dabd-1285-4bd0-b3aa-b05cc060a24a.jpg"/> </div><br>
**5. 代码实现**
**5. 代码实现**
```java
public interface Dough {
@ -738,17 +738,17 @@ MarinaraSauce
# 第五章 单件模式
**1. 模式定义**
**1. 模式定义**
确保一个类只有一个实例,并提供了一个全局访问点。
**2. 模式类图**
**2. 模式类图**
使用一个私有构造器、一个私有静态变量以及一个公有静态函数来实现。私有构造函数保证了不能通过构造函数来创建对象实例,只能通过公有静态函数返回唯一的私有静态变量。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//59aff6c1-8bc5-48e4-9e9c-082baeb2f274.jpg"/> </div><br>
**3. 懒汉式-线程不安全**
**3. 懒汉式-线程不安全**
以下实现中,私有静态变量被延迟化实例化,这样做的好处是,如果没有用到该类,那么就不会创建私有静态变量,从而节约资源。
@ -771,7 +771,7 @@ public class Singleton {
}
```
**4. 懒汉式-线程安全**
**4. 懒汉式-线程安全**
只需要对 getUniqueInstance() 方法加锁,那么在一个时间点只能有一个线程能够进入该方法,从而避免了对 uniqueInstance 进行多次实例化的问题。但是这样有一个问题,就是当一个线程进入该方法之后,其它线程视图进入该方法都必须等待,因此性能上有一定的损耗。
@ -784,7 +784,7 @@ public class Singleton {
}
```
**5. 饿汉式-线程安全**
**5. 饿汉式-线程安全**
线程不安全问题主要是由于静态实例变量被初始化了多次,那么静态实例变量采用直接实例化就可以解决问题。但是直接初始化的方法也丢失了延迟初始化节约资源的优势。
@ -792,7 +792,7 @@ public class Singleton {
private static Singleton uniqueInstance = new Singleton();
```
**6. 双重校验锁-线程安全**
**6. 双重校验锁-线程安全**
因为 uniqueInstance 只需要被初始化一次,之后就可以直接使用了。加锁操作只需要对初始化那部分的代码进行,也就是说,只有当 uniqueInstance 没有被初始化时,才需要进行加锁。
@ -822,7 +822,7 @@ public class Singleton {
# 第六章 命令模式
**1. 问题描述**
**1. 问题描述**
设计一个遥控器,它有很多按钮,每个按钮可以发起一个命令,让一个家电完成相应操作。
@ -832,11 +832,11 @@ public class Singleton {
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//c3ca36b2-8459-4cf1-98b0-cc95a0e94f20.jpg"/> </div><br>
**2. 模式定义**
**2. 模式定义**
将命令封装成对象,以便使用不同的命令来参数化其它对象。
**3. 解决方案类图**
**3. 解决方案类图**
- RemoteControl 是遥控器,它可以为每个按钮设置命令对象,并且调用命令对象的 execute() 方法。
@ -848,11 +848,11 @@ public class Singleton {
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//5ef94f62-98ce-464d-a646-842d9c72c8b8.jpg"/> </div><br>
**4. 模式类图**
**4. 模式类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//1e09d75f-6268-4425-acf8-8ecd1b4a0ef3.jpg"/> </div><br>
**5. 代码实现**
**5. 代码实现**
```java
public interface Command {
@ -935,13 +935,13 @@ Light is on!
## 1. 适配器模式
**1. 模式定义**
**1. 模式定义**
将一个类的接口,转换为客户期望的另一个接口。适配器让原本不兼容的类可以合作无间。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//8e8ba824-7a9e-4934-a212-e6a41dcc1602.jpg"/> </div><br>
**2. 模式类图**
**2. 模式类图**
有两种适配器模式的实现一种是对象方式一种是类方式。对象方式是通过组合的方法让适配器类Adapter拥有一个待适配的对象Adaptee从而把相应的处理委托给待适配的对象。类方式用到多重继承Adapter 继承 Target 和 Adaptee先把 Adapter 当成 Adaptee 类型然后实例化一个对象,再把它当成 Target 类型的,这样 Client 就可以把这个对象当成 Target 的对象来处理,同时拥有 Adaptee 的方法。
@ -949,17 +949,17 @@ Light is on!
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//a797959a-0ed5-475b-8d97-df157c672019.jpg"/> </div><br>
**3. 问题描述**
**3. 问题描述**
鸭子Duck和火鸡Turkey拥有不同的叫声Duck 调用的是 quack() 方法,而 Turkey 调用 gobble() 方法。
要求将 Turkey 的 gobble() 方法适配成 Duck 的 quack() 方法。
**4. 解决方案类图**
**4. 解决方案类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//1a511c76-bb6b-40ab-b8aa-39eeb619d673.jpg"/> </div><br>
**5. 代码实现**
**5. 代码实现**
```java
public interface Duck {
@ -1015,67 +1015,67 @@ gobble!
## 2. 外观模式
**1. 模式定义**
**1. 模式定义**
提供了一个统一的接口,用来访问子系统中的一群接口,从而让子系统更容易使用。
**2. 模式类图**
**2. 模式类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//78f2314e-2643-41df-8f3d-b7e28294094b.jpg"/> </div><br>
**3. 问题描述**
**3. 问题描述**
家庭影院中有众多电器,当要进行观看电影时需要对很多电器进行操作。要求简化这些操作,使得家庭影院类只提供一个简化的接口,例如提供一个看电影相关的接口。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//106f5585-b2e7-4718-be5d-3b322d1ef42a.jpg"/> </div><br>
**4. 解决方案类图**
**4. 解决方案类图**
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//25387681-89f8-4365-a2fa-83b86449ee84.jpg"/> </div><br>
**5. 设计原则**
**5. 设计原则**
**最少知识原则**:只和你的密友谈话。也就是应当使得客户对象所需要交互的对象尽可能少。
**最少知识原则** :只和你的密友谈话。也就是应当使得客户对象所需要交互的对象尽可能少。
**6. 代码实现**
**6. 代码实现**
过于简单,无实现。
# 第八章 模板方法模式
**1. 模式定义**
**1. 模式定义**
在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中。
模板方法使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
**2. 模式类图**
**2. 模式类图**
模板方法 templateMethod() 定义了算法的骨架,确定了 primitiveOperation1() 和 primitiveOperation2() 方法执行的顺序,而 primitiveOperation1() 和 primitiveOperation2() 让子类去实现。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//ed62f400-192c-4185-899b-187958201f0c.jpg"/> </div><br>
**3. 问题描述**
**3. 问题描述**
冲咖啡和冲茶都有类似的流程,但是某些步骤会有点不一样,要求复用那些相同步骤的代码。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//d8f873fc-00bc-41ee-a87c-c1b4c0172844.png"/> </div><br>
**4. 解决方案类图**
**4. 解决方案类图**
其中 prepareRecipe() 方法就是模板方法,它确定了其它四个方法的具体执行步骤。其中 brew() 和 addCondiments() 方法在子类中实现。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//aa20c123-b6b5-432a-83d3-45dc39172192.jpg"/> </div><br>
**5. 设计原则**
**5. 设计原则**
**好莱坞原则**:别调用(打电话给)我们,我们会调用(打电话给)你。这一原则可以防止依赖腐败,即防止高层组件依赖低层组件,低层组件又依赖高层组件。该原则在模板方法的体现为,只有父类会调用子类,子类不会调用父类。
**好莱坞原则** :别调用(打电话给)我们,我们会调用(打电话给)你。这一原则可以防止依赖腐败,即防止高层组件依赖低层组件,低层组件又依赖高层组件。该原则在模板方法的体现为,只有父类会调用子类,子类不会调用父类。
**6. 钩子**
**6. 钩子**
钩子hock某些步骤在不同实现中可有可无可以先定义一个什么都不做的方法把它加到模板方法中如果子类需要它就覆盖默认实现并加上自己的实现。
**7. 代码实现**
**7. 代码实现**
```java
public abstract class CaffeineBeverage {
@ -1159,11 +1159,11 @@ Tea.addCondiments
## 1. 迭代器模式
**1. 模式定义**
**1. 模式定义**
提供顺序访问一个聚合对象中的各个元素的方法,而又不暴露聚合对象内部的表示。
**2. 模式类图**
**2. 模式类图**
- Aggregate 是聚合类,其中 createIterator() 方法可以产生一个 Iterator 对象;
@ -1173,7 +1173,7 @@ Tea.addCondiments
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//439deca7-fed0-4c89-87e5-7088d10f1fdb.jpg"/> </div><br>
**3. 代码实现**
**3. 代码实现**
```java
public class Aggregate {
@ -1249,7 +1249,7 @@ public class Client {
## 2. Java 内置的迭代器
**1. 实现接口**
**1. 实现接口**
在使用 Java 的迭代器实现时,需要让聚合对象去实现 Iterable 接口,该接口有一个 iterator() 方法会返回一个 Iterator 对象。
@ -1257,7 +1257,7 @@ public class Client {
Java 中的集合类基本都实现了 Iterable 接口。
**2. 代码实现**
**2. 代码实现**
```java
import java.util.Iterator;
@ -1315,17 +1315,17 @@ public class Client {
## 3. 组合模式
**1. 设计原则**
**1. 设计原则**
一个类应该只有一个引起改变的原因。
**2. 模式定义**
**2. 模式定义**
允许将对象组合成树形结构来表现“整体/部分”层次结构。
组合能让客户以一致的方式处理个别对象以及组合对象。
**3. 模式类图**
**3. 模式类图**
组件Component类是组合类Composite和叶子类Leaf的父类可以把组合类看成是树的中间节点。
@ -1333,7 +1333,7 @@ public class Client {
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//f99c019e-7e91-4c2e-b94d-b031c402dcb5.jpg"/> </div><br>
**4. 代码实现**
**4. 代码实现**
```java
public abstract class Component {
@ -1436,17 +1436,17 @@ Composite:root
# 第十章 状态模式
**1. 模式定义**
**1. 模式定义**
允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它所属的类。
**2. 模式类图**
**2. 模式类图**
Context 的 request() 方法委托给 State 对象去处理。当 Context 组合的 State 对象发生改变时,它的行为也就发生了改变。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//c28fd93a-0d55-4a19-810f-72652feee00d.jpg"/> </div><br>
**3. 与策略模式的比较**
**3. 与策略模式的比较**
状态模式的类图和策略模式一样,并且都是能够动态改变对象的行为。
@ -1456,13 +1456,13 @@ Context 的 request() 方法委托给 State 对象去处理。当 Context 组合
状态模式主要是用来解决状态转移的问题,当状态发生庄毅了,那么 Context 对象就会改变它的行为;而策略模式主要是用来封装一组可以互相替代的算法族,并且可以根据需要动态地去替换 Context 需要使用哪个算法。
**4. 问题描述**
**4. 问题描述**
糖果销售机有多种状态,每种状态下销售机有不同的行为,状态可以发生转移,使得销售机的行为也发生改变。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//f7d880c9-740a-4a16-ac6d-be502281b4b2.jpg"/> </div><br>
**5. 直接解决方案**
**5. 直接解决方案**
在糖果机的每个操作函数里面,判断当前的状态,根据不同的状态进行不同的处理,并且发生不同的状态转移。
@ -1470,7 +1470,7 @@ Context 的 request() 方法委托给 State 对象去处理。当 Context 组合
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//62ebbb63-8fd7-4488-a866-76a9dc911662.png"/> </div><br>
**6 代码实现**
**6 代码实现**
糖果销售机即 Context。
@ -1757,13 +1757,13 @@ No gumball dispensed
## MVC
**传统 MVC**
**传统 MVC**
视图使用组合模式,模型使用了观察者模式,控制器使用了策略模式。
<br><div align="center"> <img src="https://github.com/CyC2018/InterviewNotes/blob/master/pics//4f67611d-492f-4958-9fa0-4948010e345f.jpg"/> </div><br>
**Web 中的 MVC**
**Web 中的 MVC**
模式不再使用观察者模式。
@ -1771,7 +1771,7 @@ No gumball dispensed
# 第十三章 与设计模式相处
定义:在某 **情境** 下,针对某 **问题** 的某种 **解决方案**
定义:在某 **情境** 下,针对某 **问题** 的某种 **解决方案**
过度使用设计模式可能导致代码被过度工程化,应该总是用最简单的解决方案完成工作,并在真正需要模式的地方才使用它。