Java设计模式综述
Posted 红日666
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Java设计模式综述相关的知识，希望对你有一定的参考价值。
Java设计模式综述 [持续更新...]
一、设计模式六大原则
设计模式的六大原则分别是：单一职责原则、开放封闭原则、里氏替换原则、依赖倒置原则、达米特原则、接口隔离原则。
1、单一职责原则
定义：
就一个类而言，应该仅有一个引起它变化的原因，即一个类或者一个方法只负责一项职责。
也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，
管好自己的事情就可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！)
这个就是说，一个类需尽量做到功能单一。比如在MVC中，判断数据的类和添加数据库的类一定要分开。单一职能的不是说职能多了我们实现不了,是为了后期的测试维护,每个类的很单一,我们找错误的时候就可以一步到位。添加新的功能的时候，也不用牵扯到很多的类。
2、开放封闭原则
定义：
类、模块、函数等可以扩展，但是不可以修改，用抽象构建架构，用实现扩展原则。
在一个系统中， 对于扩展是开放的，对于修改是关闭的，一个好的系统是在不修改源代码的情况下，可以扩展你的功能，而实现开闭原则的关键就是抽象化。
在"开-闭"原则中，不允许修改的是抽象的类或者接口，允许扩展的是具体的实现类，抽象类和接口在"开-闭"原则中扮演着极其重要的角色。即要预知可能变化的需求，又预见所有可能已知的扩展，所以在这里"抽象化"是关键!
当然对于修改，我们不可能完全避免，也不可能完全预知到未来的变化。所以我们要做到尽量去不要修改，或者少的修改就能达到我们的目标。
3、里氏替换原则
定义：
所有引用基类（父类）的地方必须能够透明地使用其子类的对象。（多态）
子类可以扩展父类的功能，但不能改变原有父类的功能。实际项目中，每个子类对应不同的业务含义，使父类作为参数，传递不同的子类完成不同的业务逻辑。这个原则是对继承的一个约束，也就是说继承中子类严格满足"is a"的关系。这里我个人有深刻的体会，尤其是在看别人的UML图的时候对你帮助很大。当你看到一个继承的时候，要习惯性的把他的父类和子类看成一个整体，这样会有助于你去理解各个类之间的关系。因为根据里氏代换原则，父类出现的地方子类也可以出现。
4、依赖倒置原则
定义：
高层模式不应该依赖低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
依赖倒置原则就是说要依赖抽象，而不要依赖具体的实现。如果说开闭原则是目标，依赖倒转原则是到达"开闭"原则的手段，如果要达到最好的"开闭"原则，就要尽量的遵守依赖倒转原则。可以说依赖倒转原则是对"抽象化"的最好规范!
通俗的说就是只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁。
通俗点就是说变量或者传参数，尽量使用抽象类，或者接口。
5、迪米特原则
定义：
一个软件实体应当尽可能少的于其他实体发生相互作用，即最少知道原则，尽量降低类与类之间的耦合。
在你的系统扩展的时候，你可能需要修改这些类，而类与类之间的关系决定了修改的复杂度，相互作用越多则修改难度就越大。反之，如果相互作用的越小则修改起来的难度就越小。例如A类依赖B类，则B类依赖C类，当你在修改A类的时候，你要考虑B类是否会受到影响，而B类的影响是否又会影响到C类。如果此时C类再依赖D类的话，我想这样的修改有的受了~~
6、接口隔离原则
定义：
一个类对另一个类的依赖应该建立在最小的接口上。即客户端不应该依赖它不需要的接口
这个法则与迪米特法则是相通的，迪米特原则是目的，而接口隔离原则是对迪米特原则的规范。为了做到尽可能小的耦合性，我们需要使用接口来规范类，用接口来约束类。要达到迪米特原则的要求，最好就是实现接口隔离原则，实现接口隔离原则你也就满足了迪米特原则。这里也体现了一个依赖原则，要尽量依赖抽象，不要依赖具体。
总结
- 单一职责原则告诉我们实现类要职责单一
- 开闭原则告诉我们要对扩展开放，对修改关闭
- 里氏替换原则告诉我们不要破坏继承体系
- 依赖倒置原则告诉我们要面向接口编程
- 迪米特原则告诉我们要降低耦合
- 接口隔离原则告诉我们在设计接口的时候要精简单一
二、设计模式分类
GoF提出的设计模式总共有23中，根据目的准则分类，可以分为三大类：
1、创建型设计模式
创建型设计模式，顾名思义就是与对象创建有关，共5种：
单例模式：
保证一个类仅有一个实例，并提供一个全局访问它的全局访问点。
工厂方法模式：
定义一个用于创建产品的接口，由子类决定生产什么产品
抽象工厂模式：
提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
建造者模式：
将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
原型模式：
将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
2、结构型设计模式
结构型设计模式，是从程序的结构上解决模块之间的耦合问题，共7种：
适配器模式：
将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
装饰者模式：
动态的给对象增加一些职责，即增加其额外的功能。
代理模式：
为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
外观模式：
为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
桥接模式：
将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
组合模式：
将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
享元模式：
运用共享技术来有效地支持大量细粒度对象的复用。
3、行为型设计模式
行为设计模式，主要处理类或对象如何交互及如何分配职责，工11种：
策略模式：
定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
模板方法模式：
定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
观察者模式：
多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
迭代器模式：
提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
责任链模式：
把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
命令模式：
将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
备忘录模式：
在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
状态模式：
允许一个对象在其内部状态发生改变时改变其行为能力。
访问者模式：
在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
中介者模式：
定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
解释器模式：
提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。
4、其他设计模式【非GoF设计模式】
生产者/消费者模式
以上是关于Java设计模式综述的主要内容，如果未能解决你的问题，请参考以下文章