# design_pattern

**Repository Path**: wh543/design_pattern

## Basic Information

- **Project Name**: design_pattern
- **Description**: 设计模式
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2019-04-28
- **Last Updated**: 2022-01-21

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# design_pattern

单一职责 定义：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且如果一个类承担的职责过多，就相当于将这个职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。
类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过方法来体现。
单一职责原则是实现高内聚，低耦合的指导方针，在很多代码重构方法都能找到它的存在，它是最简单但是又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

日常项目开发中，经常会将实现分门别类比如controller类（负责处理用户请求和参数校验），service类（负责业务逻辑控制），dao类（负责操作数据苦）等。

开闭原则 定义：一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源码的情况下改变这个模块的行为。
开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述，对可变性封装原则（EVP）要求找到系统的可变因素并将其封装起来。
如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行拓展，而且在拓展时无须修改现有的代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。

里氏替换原则 定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
里氏替换原则可以通俗表述为：在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。
里氏替换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

使用里氏替换原则需要注意：

1. 子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏替换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。
2.
我们在运用里氏替换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父类接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便得扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏替换原则时开闭原则的具体实现手段之一。
3. java语言中，在编译阶段，Java编译器会检查一个程序是否符合里氏替换原则，这是一个与实现无关的、纯语法意义上的检查，但java编译器的检查是有局限的。

依赖倒置原则 定义：抽象不应该依赖细节，细节应该依赖其抽象。换言之，要针对接口编程，而不是针对实现编程。
依赖倒置原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明、以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到子类中增加的新方法。
在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无需修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭原则的要求。
在实现依赖倒置原则时，我们需要针对抽象层编程，而将具体类的对象依赖注入（DependencyInjection，DI）的方法注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注入、设值注入和接口注入。构造注入是指通过构造函数来传入具体类的对象，设值注入是指通过Setter方法来传入具体类的对象，而接口注入是通过在声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象类覆盖父类对象。

总结：

1. 针对接口编程
2. 在接口或抽象类中定义方法、声明变量
3. 类只实现接口或抽象类中的方法，不要定义多余的方法
4. 给抽象对象或接口注入依赖对象时，采用依赖注入方式

接口隔离原则 定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些不需要的接口。
接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽量可能小的单独的接口，而不要提供大的总接口。在面向对象的编程语言中，实现一个接口就需要实现该接口中定义的所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来较为方便，并都承担某一单一角色。

合成复用原则 定义：尽量使用对象组合，而不是继承来达到复用的目的。
合成复用原则就使在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能的目的。简言之：复用时要尽量使用组合/聚合关系（关联关系），少用继承。
在面向对象设计中，可以通过两种方法在不同的环境中复用已有的设计和实现，即通过组合/聚合关系或通过继承，但首先应该考虑使用组合/聚合，组合/聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少；其次才考虑继承，在使用继承使，要严格遵循里氏替换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎用使用继承复用。
通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说时可见的，所以这种复用又称“白箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变。
由于组合和聚合关系可以将已用的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员的内部实现细节对新对象不可见。

迪米特法则（最少知道原则 ） 定义：一个软件实体应当尽可能少地与其他实体发生相互作用。
如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间的通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松耦合关系。
迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中一个对象需要调用另一个对象的某个方法时，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。

1. 单例(Singleton)模式:某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
2. 原型(Prototype)模式:将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
3. 工厂方法(Factory Method)模式:定义一个用于创建产品的接口，由子类决定生产什么产品。
4. 抽象工厂(AbstractFactory)模式:提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
5. 建造者(Builder)模式:将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
6. 代理(Proxy)模式:为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
7. 适配器(Adapter)模式:将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
8. 桥接(Bridge)模式:将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
9. 装饰(Decorator)模式:动态的给对象增加一些职责，即增加其额外的功能。
10. 外观(Facade)模式:为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
11. 享元(Flyweight)模式:运用共享技术来有效地支持大量细粒度对象的复用。
12. 组合(Composite)模式:将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
13. 模板方法(TemplateMethod)模式:定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
14. 策略(Strategy)模式:定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
15. 命令(Command)模式:将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
16. 职责链(Chain of Responsibility)模式:把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
17. 状态(State)模式:允许一个对象在其内部状态发生改变时改变其行为能力。
18. 观察者(Observer)模式:多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象， 从而影响其他对象的行为。
19. 中介者(Mediator)模式:定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有 对象之间不必相互了解。
20. 迭代器(Iterator)模式:提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
21. 访问者(Visitor)模式:在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多 个访问者对象访问。
22. 备忘录(Memento)模式:在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
23. 解释器(Interpreter)模式:提供如何定义语言的方法，以及对语言句子的解释方法，即解释器。