java设计模式汇总

java设计模式分类

一 java设计模式遵循六大原则

1、单一职责（Single Responsibilitiy Principle）

• Single-Responsibilitiy Principle：对一个类而言，应该仅有一个引起它变化的原因。
  如果存在多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该把多余的职责分离出去，再去创建一些类来完成每一个职责。单一职责原则的优点：
  1.降低类的复杂度，一个类只负责一个职责。这样写出来的代码逻辑肯定要比负责多项职责简单得多。单一职责原则是实现高内聚低耦合的最好方法，没有之一。
  2.提高类的可读性，提高系统的可维护性。
  3.降低变更引起的风险。变更是必然的，如果单一职责原则遵守得好，当修改一个功能的时候可以显著降低对其他功能的影响。
  需要说明的一点是，单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。比如说单一职责原则不仅仅适用于类，还适用于方法。

2、开闭原则（Open Close Principle）

• Open-Close Principle（OCP）：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。目的就是保证程序的扩展性好，易于维护和升级。
  对于扩展是开放的，对于更改是封闭的。 开放-封闭原则是面向对象设计的核心所在, 开闭原则是Java世界里最基础的设计原则。
  开闭原则被称为面向对象设计的基石，实际上，其他原则都可以看作是实现开闭原则的工具和手段。意思就是：软件对扩展应该是开放的，对修改是封闭的，通俗来说就是，开发一个软件时，应该对其进行功能扩展，而在进行这些扩展时，不需要对原来的程序进行修改。

3、里氏代换原则（Liskov Substitution Principle）

• Liskov Substitution Principle：子类可以扩展父类的功能，但是不能改变父类原有的功能。
  子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
  子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法，父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。
  保证了父类的复用性，同时也能够降低系统出错误的故障，防止误操作，同时也不会破坏继承的机制，这样继承才显得更有意义。 总结：
  里氏代换原则规定子类不得重写父类的普通方法，只能重写父类的抽象方法，程序员们实际设计软件时如果非要继承的话，设计继承抽象类，而不要继承普通类。

4、依赖倒转原则（Dependence Inversion Principle）

• Dependence Inversion Principle：是一个类与类之间的调用规则。这里的依赖就是代码中的耦合。高层模块不应该依赖底层模块，二者都应该依赖其抽象了；抽象不依赖细节；细节应该依赖抽象、接口编程。
  问题由来
  类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
  解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
  依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
  依赖倒置原则的核心思想是面向接口编程。 在实际编程中，我们一般需要做到如下3点： 低层模块尽量都要有抽象类或接口，或者两者都有。
  变量的声明类型尽量是抽象类或接口。 使用继承时遵循里氏替换原则。
  依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。

5、接口隔离原则（Interface Segregation Principle）

• Interface Segregation Principle：用于恰当的划分角色和接口，具有两种含义：1、用户不应该依赖它不需要的接口；2、类间的依赖关系应该建立在最小的的接口上。
  将这两个定义概括为一句话：建立单一接口，代替庞大臃肿的接口。通俗来说就是：接口尽量细化，同时保证接口中的方法尽量的少。一个接口中包含太多的行为时，会导致它们与客户端的不正常依赖关系，要做的就是分离接口，从而实现解耦。
  回到上述的单一职责原则，要求行为分离接口接口细化，感觉有些相同。但实际上，单一职责原则要求类与接口的职责单一，注重的是职责，没有要求接口尽量的少。
  在接口隔离原则中，要求尽量使用多个专门的接口。专门的接口也就是提供给多个模块的接口。提供给几个模块就应该有几个接口，而不是建立一个臃肿庞大的接口，所有的模块都可以访问。
  但是接口的设计是有限度的。接口的设计粒度越小系统越灵活，这是事实，但是接口太多这也就使得结构复杂，维护难度大。因此实际中，怎样把握就靠开发的经验和常识了。

6、迪米特法则（最少知道原则）（Demeter Principle）

• Law of Demeter：一个对象应该对其他对象有最少的了解。通俗来说就是，一个类对自己需要耦合或者调用的类知道的最少，你类内部怎么复杂，我不管，那是你的事，我只知道你有那么多公用的方法，我能调用。
  迪米特原则核心观念就是：类间解耦，弱耦合。 从迪米特法则的定义和特点可知，它强调以下两点： 从依赖者的角度来说，只依赖应该依赖的对象。
  从被依赖者的角度说，只暴露应该暴露的方法。 迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。
  降低了类之间的耦合度，提高了模块的相对独立性。 由于亲合度降低，从而提高了类的可复用率和系统的扩展性

二 java设计模式基本可分为三大类，二十三种小类

1. 创建型模式（创建对象的模式，抽象了实例化过程），共五种：

• 工厂方法模式Factory：定义一个用于创建对象的接口，让子类决定实例化哪一个类抽象工厂模式Abstract Factory：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类
• 抽象工厂模式Abstract Factory：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类
• 单例模式Singleton：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例
• 原型模式Prototype：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
• 建造者模式Builder：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示

2. 结构型模式（侧重于接口使用，一切工作是围绕对象和类之间的交互，提供一个门，成就一个你来我往），共七种：

• 适配器模式Adapter：将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作
• 装饰器模式Decorator：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活
• 代理模式Proxy：为其他对象提供一种代理以控制对这个对象的访问
• 外观模式Facade：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供了一个高层次的接口，使得子系统更容易使用
• 桥接模式Bridge：将抽象和实现解耦，使得两者可以独立的变化
• 组合模式Composite：将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性
• 享元模式Flyweight：使用共享对象可有效地支持大量的细粒度对象

3. 行为型模式（侧重于具体行为，是对不同对象的职责划分和算法的抽象化），共十一种：

• 策略模式Strategy： 定义一组算法，将每个算法都封装起来，并且使他们之间可以互换

• 模板方法模式Template Method： 定义一个操作中的算法框架，而将一些步骤延迟到子类中

• 观察者模式Observer：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新

• 迭代模式Iterator：它提供一种方法访问一个容器对象中各个元素，而又不需要暴露该对象的内部细节

• 责任链模式Chain of Responsibility：使多个对象有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系 。将这些对象连成一个链，并沿着这条链传递请求，知道有对象处理它为止

• 命令模式Command：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能

• 备忘录模式Memento：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可将该对象恢复到原来保存的状态

• 状态模式State：当一个对象在状态改变时允许其改变行为，这个对象看起来像改变了其类

• 访问者模式Visitor：封装一些作用于某种数据结构中的各种元素，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作

• 中介者模式Mediator：用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示的相互作用，从而使其耦合松散，而且可以独立的改变它们之间的交互

• 解释器模式Interpreter：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子
  总结出各种模式是为了提高代码的复用性、可读性，之后也会将每个模式链接地址更新到此。