# design_patterns

**Repository Path**: unidentifiable/design_patterns

## Basic Information

- **Project Name**: design_patterns
- **Description**: 设计模式
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-07-14
- **Last Updated**: 2021-07-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 设计模式Java版
```
├─设计模式概述
│  ├─设计模式概念: 设计一个模式的过程就是将问题抽象化，忽略不重要的细节后发现问题的本质，并找到普遍适用的解决方案的过程
│  ├─设计模式简史: 设计模式起源于建筑设计学
│  ├─设计模式要素
│  │  ├─名字
│  │  ├─问题
│  │  ├─初始环境
│  │  ├─举例
│  │  ├─末态环境
│  │  ├─推理
│  │  ├─其他有关模式
│  │  ├─已知应用
│
│  ├─设计模式分类
│  │  ├─创建型
│  │  ├─行为型
│  │  ├─结构型
│
├─设计原则
│  ├─单一职责原则
│  ├─里氏替换原则
│  ├─依赖倒置原则
│  ├─接口隔离原则
│  ├─迪米特法则
│  ├─开闭原则
│
├─创建型模式
│  ├─单例模式（Singleton Pattern）
│  ├─工厂方法模式（Factory Pattern）
│  ├─抽象工厂模式（Abstract Factory）
│  ├─建造者模式（Builder Pattern）
│  ├─原型模式（Prototype Pattern）
│
├─结构型模式
│  ├─代理模式（Proxy）
│  ├─装饰模式（Decorator）
│  ├─适配器模式（Adapter）
│  ├─组合模式（Composite）
│  ├─桥梁模式（Bridge）
│  ├─外观模式（Facade）
│  ├─享元模式（Flyweight）
│
├─行为型模式
│  ├─模板方法模式（Template Method）
│  ├─命令模式（Command）
│  ├─责任链模式（Chain of Responsibility）
│  ├─策略模式（Strategy）
│  ├─迭代器模式（Iterator）
│  ├─中介者模式（Mediator）
│  ├─观察者模式（Observer）
│  ├─备忘录模式（Memento）
│  ├─访问者模式（Visitor）
│  ├─状态模式（State）
│  ├─解释器模式（Interpreter）
│
├─设计模式对比
│
```

## 创建型
```
创建型模式是用来创建对象的模式，抽象了实例化的过程，帮助一个系统独立于其关联对象的创建、组合和表示方式。所有的创建型模式都有两个主要功能：
    ■ 将系统所使用的具体类的信息封装起来；
    ■ 隐藏类的实例是如何被创建和组织的。外界对于这些对象只知道它们共同的接口，而不清楚其具体的实现细节。

创建型模式的作用可以概括为如下两点。
    ■ 封装创建逻辑，不仅仅是new一个对象那么简单；
    ■ 封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。

常见的创建型设计模式有下列几种。
    ■ 单例模式（Singleton Pattern）：
        一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

    ■ 工厂方法模式（Factory Pattern）：
        在工厂方法模式中，工厂类成为了抽象类，实际的创建工作将由其具体子类来完成。
        工厂方法的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中去，强调的是“单个对象”的变化。

    ■ 抽象工厂模式（Abstract Factory）：
        抽象工厂是所有工厂模式中最为抽象和最具有一般性的一种形态。
        抽象工厂可以向客户提供一个接口，使得客户可以在不必指定产品具体类型的情况下，创建多个产品族中的产品对象，强调的是“系列对象”的变化。

    ■ 建造者模式（Builder Pattern）：
        把构造对象实例的逻辑移到了类的外部，在类的外部定义了该类的构造逻辑。
        它把一个复杂对象的构造过程从对象的表示中分离出来，其直接效果是将一个复杂的对象简化为一个比较简单的目标对象，强调的是产品的构造过程。

    ■ 原型模式（Prototype Pattern）：
        原型模式和工厂模式一样，同样对客户隐藏了对象创建工作，但与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过复制一个现有对象生成新对象
```

## 结构型
```
结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象实现新的功能（对象结构型模式）。
这些结构型模式在某些方面具有很大的相似性，但侧重点却各有不同。

常见的结构型设计模式有以下几种。
    ■ 代理模式（Proxy）：
        为其他对象提供一种代理以控制对该对象的访问。

    ■ 装饰模式（Decorator）：
        动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。

    ■ 适配器模式（Adapter）：
        将一个类的接口变换成客户端所期待的另一接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

    ■ 组合模式（Composite）：
        也叫合成模式，将对象组合成树形结构以表示“部分—整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

    ■ 桥梁模式（Bridge）：
        也叫桥接模式，将抽象和实现解耦，使得两者可以独立变化。

    ■ 外观模式（Facade）：
        也叫门面模式，要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，外观模式提供一个高层次的接口，使得子系统更易于使用。

    ■ 享元模式（Flyweight）：
        是池技术的重要实现方式，使用共享对象可有效地支持大量的细粒度的对象。
```

## 行为型
```
行为型设计模式关注的是对象的行为，用来解决对象之间的联系问题。

常见的行为型设计模式有以下几种。
    ■ 模板方法模式（Template Method）：
        定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
    
    ■ 命令模式（Command）：
        是一种高内聚的模式，将一个请求封装成一个对象，从而使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
    
    ■ 责任链模式（Chain of Responsibility）：
        使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
    
    ■ 策略模式（Strategy）：
        也叫政策模式，定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。
    
    ■ 迭代器模式（Iterator）：
        提供一种方法访问一个容器对象中的各个元素，而又不需要暴露该对象的内部细节。
    
    ■ 中介者模式（Mediator）：
        用一个中介对象封装一系列的对象交互，中介者使各对象不需要显式地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
    
    ■ 观察者模式（Observer）：
        也叫发布订阅模式，定义对象间的一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
    
    ■ 备忘录模式（Memento）：
        在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
    
    ■ 访问者模式（Visitor）：
        封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
    
    ■ 状态模式（State）：
        当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类型，状态模式的核心是封装，状态的变更引起行为的变更。
    
    ■ 解释器模式（Interpreter）：
        给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该文法表示来解释语言中的句子。
```

## 设计原则
### 单一职责原则
```
单一职责原则的英文名称是Single Responsibility Principle，简称SRP。
定义：
    一个类，应当只有一个引起它变化的原因；即一个类应该只有一个职责。

优点：
    ■ 降低类的复杂性；
    ■ 提高类的可读性；
    ■ 提高代码的可维护性和复用性；
    ■ 降低因变更引起的风险。

应用：
    以用户管理为例演示单一职责原则。
    在业务逻辑层中定义类 UserManager，在数据访问层定义类 UserDao，在实体对象层定义类 User，每个类具有不同的职责和功能
    参考: com.king.designpatterns.七大原则.单一职责

    单一职责原则提出了一个编写程序的标准，
    用“职责”或“变化原因”来衡量接口或类设计是否优良，
    但“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异
```

### 里氏替换原则 
```
里氏替换原则的英文名称是：Liskov Substitution Principle，简称LSP。
定义：
    一、如果对于类型S的每个对象o1，都存在类型T的对象o2，使得对于用S定义的所有程序P，当用o1代替o2时P的行为不变，则T是S的子类型。
    二、使用指针或对基类的引用的函数必须能够使用派生类的对象，而无需对其进行了解。
    
里氏替换原则为良好的继承定义了一个规范，它包含4层含义：  
    ■ 子类必须完全实现父类的方法；
    ■ 子类可以有自己的个性；
    ■ 覆盖或实现父类的方法时输入参数可以被放大；
    ■ 覆盖或实现父类的方法时输出结果可以被缩小。

优点：
    ■ 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
    ■ 提高代码的可重用性；
    ■ 提高代码的可扩展性；
    ■ 提高产品或项目的开放性。

缺点：
    ■ 继承是入侵式的。只要继承，就必须拥有父类的所有属性和方法；
    ■ 降低代码的灵活性。子类必须拥有父类的属性和方法，使子类受到限制；
    ■ 增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种修改可能造成大片的代码需要重构。
    
应用：
    在编译期，Java语言编译器会检查一个程序是否符合里氏替换原则，这是一个无关实现的、纯语法意义上的检查。
    例如，一个基类Base声明了一个public方法method()，其子类Sub就不能将该方法的访问权限从public改换成为private或protected。
    
体现：
    ■ 策略模式
    ■ 组合模式
    ■ 代理模式
```

### 依赖倒置原则
```
依赖倒置原则英文名称是：Dependence Inversion Principle，简称DIP。

定义：
    ■ 高层模块不应该依赖低层模块，两者都依赖其抽象；
    ■ 抽象不依赖细节；
    ■ 细节应该依赖于抽象。
    
规则：
    ■ 每个类尽量都具有接口或抽象类，或者抽象类和接口两者都具备。这是依赖倒置的基本要求，接口和抽象类都是抽象的，有了抽象才可能有依赖倒置；
    ■ 变量的表面类型尽量是接口或者是抽象类；
    ■ 任何类都不应该从具体类派生；
    ■ 尽量不要重写基类的方法。如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要重写。
        类之间依赖的是抽象，重写了非抽象方法，对依赖的稳定性会产生一定的影响；
    ■ 结合里氏替换原则使用。里氏替换原则指出父类出现的地方子类就可以出现，结合依赖倒置原则可以得出一个通俗的规则：
        接口负责定义抽象方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确地实现业务逻辑，同时在适当的时候对父类进行细化。
    
应用：
    ■ 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生；
    ■ 接口或抽象类不依赖于实现类；
    ■ 实现类依赖于接口或抽象类。
```

### 接口隔离原则
```
接口隔离原则的英文名称是：Interface Segregation Principle，简称ISP。

概念：
    ■ 实例接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的事物所具有的方法特征的描述，
        也称做一个“接口”，这仅是一种逻辑上的抽象。例如，定义一个Person类，使用Person zhangsan = new Person()产生一个实例，
        该实例遵从的标准是Person这个类，Person就是zhangsan的接口。
    ■ 类接口（Class Interface），是指在 Java 中使用 interface 严格定义的接口，例如，java.lang.Runnable就是一个Java线程接口。
    
定义：
    一、客户端不应该依赖它不需要的接口。
    二、类间的依赖关系应该建立在最小的接口上。
    
含义：
    ■ 一个类对另外一个类的依赖性应当是建立在最小的接口上的。
    ■ 一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。
        因此使用多个专门的接口比使用单一的总接口要好。
    ■ 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构，即不要强迫客户使用它们不用的方法，
        否则这些客户就会面临由于这些不使用的方法的改变所带来的改变。
        
应用：
    接口隔离原则的应用场合，只提供调用者需要的方法，屏蔽不需要的方法。
        ■ 一个是门户，只能有查询方法；
        ■ 一个是外部系统，有添加订单的方法；
        ■ 一个是管理后台，添加、删除、修改、查询都要用到。
        
规则：
    ■ 一个接口只对一个子模块或者业务逻辑进行服务；
    ■ 只保留接口中业务逻辑需要的public方法；
    ■ 尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理；
    ■ 接口设计应因项目而异，因环境而异，不能教条照搬。
```

### 迪米特法则
```
迪米特法则英文名称是Law of Demeter，简称LoD。

表述：
    ■ 只与你直接的朋友们通信（Only talk to your immediate friends）；
    ■ 不要跟“陌生人”说话（Don't talk to strangers）；
    ■ 每一个软件单位对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密切相关的软件单位。
    
应用：
    AB关联，BC关联，AC不关联，A可以通过B调用C的方法，而不必在本类中引入C对象

体现：
    ■ 外观模式
    ■ 中介者模式
```

### 开闭原则
```
开闭原则的英文名称是Open-Closed Principle，简称OCP。

定义：
    一个软件实体应当对扩展开放，对修改关闭。
    
体现：
    ■ 开闭原则提高复用性。
    ■ 开闭原则提高可维护性。
    ■ 开闭原则提高灵活性。
    ■ 开闭原则易于测试。
    
应用：
    Book类的price属性值固定，要修改值的时候，不对该类进行修改，新增Book子类，修改getPrice方法。
```