更新upstream
This commit is contained in:
xiongraorao
113
notes/设计模式.md
113
notes/设计模式.md
@ -62,9 +62,9 @@
|
||||
|
||||
（一）懒汉式-线程不安全
|
||||
|
||||
以下实现中，私有静态变量 uniqueInstance 被延迟化实例化，这样做的好处是，如果没有用到该类，那么就不会实例化 uniqueInstance，从而节约资源。
|
||||
以下实现中，私有静态变量 uniqueInstance 被延迟实例化，这样做的好处是，如果没有用到该类，那么就不会实例化 uniqueInstance，从而节约资源。
|
||||
|
||||
这个实现在多线程环境下是不安全的，如果多个线程能够同时进入 `if (uniqueInstance == null)` ，并且此时 uniqueInstance 为 null，那么多个线程会执行 `uniqueInstance = new Singleton();` 语句，这将导致多次实例化 uniqueInstance。
|
||||
这个实现在多线程环境下是不安全的，如果多个线程能够同时进入 `if (uniqueInstance == null)` ，并且此时 uniqueInstance 为 null，那么会有多个线程执行 `uniqueInstance = new Singleton();` 语句，这将导致多次实例化 uniqueInstance。
|
||||
|
||||
```java
|
||||
public class Singleton {
|
||||
@ -83,11 +83,21 @@ public class Singleton {
|
||||
}
|
||||
```
|
||||
|
||||
（二）懒汉式-线程安全
|
||||
（二）饿汉式-线程安全
|
||||
|
||||
只需要对 getUniqueInstance() 方法加锁，那么在一个时间点只能有一个线程能够进入该方法，从而避免了对 uniqueInstance 进行多次实例化的问题。
|
||||
线程不安全问题主要是由于 uniqueInstance 被多次实例化，采取直接实例化 uniqueInstance 的方式就不会产生线程不安全问题。
|
||||
|
||||
但是这样有一个问题，就是当一个线程进入该方法之后，其它线程试图进入该方法都必须等待，因此性能上有一定的损耗。
|
||||
但是直接实例化的方式也丢失了延迟实例化带来的节约资源的好处。
|
||||
|
||||
```java
|
||||
private static Singleton uniqueInstance = new Singleton();
|
||||
```
|
||||
|
||||
（三）懒汉式-线程安全
|
||||
|
||||
只需要对 getUniqueInstance() 方法加锁，那么在一个时间点只能有一个线程能够进入该方法，从而避免了多次实例化 uniqueInstance 的问题。
|
||||
|
||||
但是当一个线程进入该方法之后，其它试图进入该方法的线程都必须等待，因此性能上有一定的损耗。
|
||||
|
||||
```java
|
||||
public static synchronized Singleton getUniqueInstance() {
|
||||
@ -98,17 +108,9 @@ public static synchronized Singleton getUniqueInstance() {
|
||||
}
|
||||
```
|
||||
|
||||
（三）饿汉式-线程安全
|
||||
|
||||
线程不安全问题主要是由于 uniqueInstance 被实例化了多次，如果 uniqueInstance 采用直接实例化的话，就不会被实例化多次，也就不会产生线程不安全问题。但是直接实例化的方式也丢失了延迟实例化带来的节约资源的优势。
|
||||
|
||||
```java
|
||||
private static Singleton uniqueInstance = new Singleton();
|
||||
```
|
||||
|
||||
（四）双重校验锁-线程安全
|
||||
|
||||
uniqueInstance 只需要被实例化一次，之后就可以直接使用了。加锁操作只需要对实例化那部分的代码进行。也就是说，只有当 uniqueInstance 没有被实例化时，才需要进行加锁。
|
||||
uniqueInstance 只需要被实例化一次，之后就可以直接使用了。加锁操作只需要对实例化那部分的代码进行，只有当 uniqueInstance 没有被实例化时，才需要进行加锁。
|
||||
|
||||
双重校验锁先判断 uniqueInstance 是否已经被实例化，如果没有被实例化，那么才对实例化语句进行加锁。
|
||||
|
||||
@ -133,7 +135,7 @@ public class Singleton {
|
||||
}
|
||||
```
|
||||
|
||||
考虑下面的实现，也就是只使用了一个 if 语句。在 uniqueInstance == null 的情况下，如果两个线程同时执行 if 语句，那么两个线程就会同时进入 if 语句块内。虽然在 if 语句块内有加锁操作，但是两个线程都会执行 `uniqueInstance = new Singleton();` 这条语句，只是先后的问题，也就是说会进行两次实例化，从而产生了两个实例。因此必须使用双重校验锁，也就是需要使用两个 if 语句。
|
||||
考虑下面的实现，也就是只使用了一个 if 语句。在 uniqueInstance == null 的情况下，如果两个线程同时执行 if 语句，那么两个线程就会同时进入 if 语句块内。虽然在 if 语句块内有加锁操作，但是两个线程都会执行 `uniqueInstance = new Singleton();` 这条语句，只是先后的问题，那么就会进行两次实例化，从而产生了两个实例。因此必须使用双重校验锁，也就是需要使用两个 if 语句。
|
||||
|
||||
```java
|
||||
if (uniqueInstance == null) {
|
||||
@ -159,7 +161,7 @@ uniqueInstance 采用 volatile 关键字修饰也是很有必要的。`uniqueIns
|
||||
|
||||
这种方式不仅具有延迟初始化的好处，而且由虚拟机提供了对线程安全的支持。
|
||||
|
||||
```source-java
|
||||
```java
|
||||
public class Singleton {
|
||||
|
||||
private Singleton() {
|
||||
@ -175,7 +177,7 @@ public class Singleton {
|
||||
}
|
||||
```
|
||||
|
||||
（五）枚举实现
|
||||
（六）枚举实现
|
||||
|
||||
这是单例模式的最佳实践，它实现简单，并且在面对复杂的序列化或者反射攻击的时候，能够防止实例化多次。
|
||||
|
||||
@ -231,27 +233,9 @@ public class Singleton implements Serializable {
|
||||
|
||||
简单工厂不是设计模式，更像是一种编程习惯。它把实例化的操作单独放到一个类中，这个类就成为简单工厂类，让简单工厂类来决定应该用哪个具体子类来实例化。
|
||||
|
||||
<div align="center"> <img src="../pics//c79da808-0f28-4a36-bc04-33ccc5b83c13.png"/> </div><br>
|
||||
|
||||
这样做能把客户类和具体子类的实现解耦，客户类不再需要知道有哪些子类以及应当实例化哪个子类。因为客户类往往有多个，如果不使用简单工厂，所有的客户类都要知道所有子类的细节。而且一旦子类发生改变，例如增加子类，那么所有的客户类都要进行修改。
|
||||
|
||||
如果存在下面这种代码，就需要使用简单工厂将对象实例化的部分放到简单工厂中。
|
||||
|
||||
```java
|
||||
public class Client {
|
||||
public static void main(String[] args) {
|
||||
int type = 1;
|
||||
Product product;
|
||||
if (type == 1) {
|
||||
product = new ConcreteProduct1();
|
||||
} else if (type == 2) {
|
||||
product = new ConcreteProduct2();
|
||||
} else {
|
||||
product = new ConcreteProduct();
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
<div align="center"> <img src="../pics//c79da808-0f28-4a36-bc04-33ccc5b83c13.png"/> </div><br>
|
||||
|
||||
### 实现
|
||||
|
||||
@ -275,6 +259,27 @@ public class ConcreteProduct2 implements Product {
|
||||
}
|
||||
```
|
||||
|
||||
以下的 Client 类中包含了实例化的代码，这是一种错误的实现，如果在客户类中存在实例化代码，就需要将代码放到简单工厂中。
|
||||
|
||||
```java
|
||||
public class Client {
|
||||
public static void main(String[] args) {
|
||||
int type = 1;
|
||||
Product product;
|
||||
if (type == 1) {
|
||||
product = new ConcreteProduct1();
|
||||
} else if (type == 2) {
|
||||
product = new ConcreteProduct2();
|
||||
} else {
|
||||
product = new ConcreteProduct();
|
||||
}
|
||||
// do something with the product
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
以下的 SimpleFactory 是简单工厂实现，它被所有需要进行实例化的客户类调用。
|
||||
|
||||
```java
|
||||
public class SimpleFactory {
|
||||
public Product createProduct(int type) {
|
||||
@ -293,6 +298,7 @@ public class Client {
|
||||
public static void main(String[] args) {
|
||||
SimpleFactory simpleFactory = new SimpleFactory();
|
||||
Product product = simpleFactory.createProduct(1);
|
||||
// do something with the product
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -301,7 +307,7 @@ public class Client {
|
||||
|
||||
### 意图
|
||||
|
||||
定义了一个创建对象的接口，但由子类决定要实例化哪个类。工厂方法把实例化推迟到子类。
|
||||
定义了一个创建对象的接口，但由子类决定要实例化哪个类。工厂方法把实例化操作推迟到子类。
|
||||
|
||||
### 类图
|
||||
|
||||
@ -1853,11 +1859,7 @@ No gumball dispensed
|
||||
|
||||
### 与状态模式的比较
|
||||
|
||||
状态模式的类图和策略模式类似，并且都是能够动态改变对象的行为。
|
||||
|
||||
但是状态模式是通过状态转移来改变 Context 所组合的 State 对象，而策略模式是通过 Context 本身的决策来改变组合的 Strategy 对象。
|
||||
|
||||
所谓的状态转移，是指 Context 在运行过程中由于一些条件发生改变而使得 State 对象发生改变，注意必须要是在运行过程中。
|
||||
状态模式的类图和策略模式类似，并且都是能够动态改变对象的行为。但是状态模式是通过状态转移来改变 Context 所组合的 State 对象，而策略模式是通过 Context 本身的决策来改变组合的 Strategy 对象。所谓的状态转移，是指 Context 在运行过程中由于一些条件发生改变而使得 State 对象发生改变，注意必须要是在运行过程中。
|
||||
|
||||
状态模式主要是用来解决状态转移的问题，当状态发生转移了，那么 Context 对象就会改变它的行为；而策略模式主要是用来封装一组可以互相替代的算法族，并且可以根据需要动态地去替换 Context 使用的算法。
|
||||
|
||||
@ -1971,7 +1973,7 @@ public abstract class CaffeineBeverage {
|
||||
```
|
||||
|
||||
```java
|
||||
public class Coffee extends CaffeineBeverage{
|
||||
public class Coffee extends CaffeineBeverage {
|
||||
@Override
|
||||
void brew() {
|
||||
System.out.println("Coffee.brew");
|
||||
@ -1985,7 +1987,7 @@ public class Coffee extends CaffeineBeverage{
|
||||
```
|
||||
|
||||
```java
|
||||
public class Tea extends CaffeineBeverage{
|
||||
public class Tea extends CaffeineBeverage {
|
||||
@Override
|
||||
void brew() {
|
||||
System.out.println("Tea.brew");
|
||||
@ -2240,7 +2242,7 @@ Number of items: 6
|
||||
|
||||
### 意图
|
||||
|
||||
使用什么都不做的空对象来替代 NULL。
|
||||
使用什么都不做的空对象来代替 NULL。
|
||||
|
||||
一个方法返回 NULL，意味着方法的调用端需要去检查返回值是否是 NULL，这么做会导致非常多的冗余的检查代码。并且如果某一个调用端忘记了做这个检查返回值，而直接使用返回的对象，那么就有可能抛出空指针异常。
|
||||
|
||||
@ -2395,7 +2397,7 @@ public abstract class TV {
|
||||
```
|
||||
|
||||
```java
|
||||
public class Sony extends TV{
|
||||
public class Sony extends TV {
|
||||
@Override
|
||||
public void on() {
|
||||
System.out.println("Sony.on()");
|
||||
@ -2414,7 +2416,7 @@ public class Sony extends TV{
|
||||
```
|
||||
|
||||
```java
|
||||
public class RCA extends TV{
|
||||
public class RCA extends TV {
|
||||
@Override
|
||||
public void on() {
|
||||
System.out.println("RCA.on()");
|
||||
@ -2553,9 +2555,6 @@ public abstract class Component {
|
||||
```
|
||||
|
||||
```java
|
||||
import java.util.ArrayList;
|
||||
import java.util.List;
|
||||
|
||||
public class Composite extends Component {
|
||||
|
||||
private List<Component> child;
|
||||
@ -2661,7 +2660,7 @@ Composite:root
|
||||
|
||||
### 类图
|
||||
|
||||
装饰者（Decorator）和具体组件（ConcreteComponent）都继承自组件（Component），具体组件的方法实现不需要依赖于其它对象，而装饰者组合了一个组件，这样它可以装饰其它装饰者或者具体组件。所谓装饰，就是把这个装饰者套在被装饰上，从而动态扩展被装饰者的功能。装饰者的方法有一部分是自己的，这属于它的功能，然后调用被装饰者的方法实现，从而也保留了被装饰者的功能。可以看到，具体组件应当是装饰层次的最低层，因为只有具体组件的方法实现不需要依赖于其它对象。
|
||||
装饰者（Decorator）和具体组件（ConcreteComponent）都继承自组件（Component），具体组件的方法实现不需要依赖于其它对象，而装饰者组合了一个组件，这样它可以装饰其它装饰者或者具体组件。所谓装饰，就是把这个装饰者套在被装饰者之上，从而动态扩展被装饰者的功能。装饰者的方法有一部分是自己的，这属于它的功能，然后调用被装饰者的方法实现，从而也保留了被装饰者的功能。可以看到，具体组件应当是装饰层次的最低层，因为只有具体组件的方法实现不需要依赖于其它对象。
|
||||
|
||||
<div align="center"> <img src="../pics//137c593d-0a9e-47b8-a9e6-b71f540b82dd.png"/> </div><br>
|
||||
|
||||
@ -2772,7 +2771,7 @@ public class Client {
|
||||
|
||||
### 实现
|
||||
|
||||
观看电影需要操作很多电器，使用外观模式可以实现一键看电影功能。
|
||||
观看电影需要操作很多电器，使用外观模式实现一键看电影功能。
|
||||
|
||||
```java
|
||||
public class SubSystem {
|
||||
@ -2813,7 +2812,7 @@ public class Client {
|
||||
|
||||
### 设计原则
|
||||
|
||||
最少知识原则：只和你的密友谈话。也就是客户对象所需要交互的对象应当尽可能少。
|
||||
最少知识原则：只和你的密友谈话。也就是说客户对象所需要交互的对象应当尽可能少。
|
||||
|
||||
## 6. 享元（Flyweight）
|
||||
|
||||
@ -2824,8 +2823,8 @@ public class Client {
|
||||
### 类图
|
||||
|
||||
- Flyweight：享元对象
|
||||
- IntrinsicState：内部状态，相同的项元对象共享
|
||||
- ExtrinsicState：外部状态
|
||||
- IntrinsicState：内部状态，享元对象共享内部状态
|
||||
- ExtrinsicState：外部状态，每个享元对象的外部状态不同
|
||||
|
||||
<div align="center"> <img src="../pics//d52270b4-9097-4667-9f18-f405fc661c99.png"/> </div><br>
|
||||
|
||||
@ -2856,8 +2855,6 @@ public class ConcreteFlyweight implements Flyweight {
|
||||
```
|
||||
|
||||
```java
|
||||
import java.util.HashMap;
|
||||
|
||||
public class FlyweightFactory {
|
||||
|
||||
private HashMap<String, Flyweight> flyweights = new HashMap<>();
|
||||
@ -2915,7 +2912,7 @@ Java 利用缓存来加速大量小对象的访问时间。
|
||||
- 远程代理（Remote Proxy）：控制对远程对象（不同地址空间）的访问，它负责将请求及其参数进行编码，并向不同地址空间中的对象发送已经编码的请求。
|
||||
- 虚拟代理（Virtual Proxy）：根据需要创建开销很大的对象，它可以缓存实体的附加信息，以便延迟对它的访问，例如在网站加载一个很大图片时，不能马上完成，可以用虚拟代理缓存图片的大小信息，然后生成一张临时图片代替原始图片。
|
||||
- 保护代理（Protection Proxy）：按权限控制对象的访问，它负责检查调用者是否具有实现一个请求所必须的访问权限。
|
||||
- 智能代理（Smart Reference）：取代了简单的指针，它在访问对象时执行一些附加操作：记录对象的引用次数，比如智能智能；当第一次引用一个持久化对象时，将它装入内存；在访问一个实际对象前，检查是否已经锁定了它，以确保其它对象不能改变它。
|
||||
- 智能代理（Smart Reference）：取代了简单的指针，它在访问对象时执行一些附加操作：记录对象的引用次数；当第一次引用一个持久化对象时，将它装入内存；在访问一个实际对象前，检查是否已经锁定了它，以确保其它对象不能改变它。
|
||||
|
||||
<div align="center"> <img src="../pics//a6c20f60-5eba-427d-9413-352ada4b40fe.png"/> </div><br>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user