23种设计模式简单总结
java23种设计模式。:
1.设计模式入门
1.设计模式是人们在面对同类型软件工程设计问题所总结出的一些有用经验。模式不是代码，而是某类问题的通用设计解决方案
OOP是原则，设计模式是具体方法、工具。
2.策略模式
3.观察者模式:
4.装饰者模式
java 中IO流的设计就是我们其中的装饰者模式
5.单例模式
我们将构造方法私有化，提供一个静态的方法去返回实例，使其只保留一个。
6.工厂模式
7.命令模式
我们将每个命令单独写成一个类，如果需要增加新的命令也无需修改代码，只需要去增加或减少一个类。
8.适配器模式
适配器相当于一个转换器
9.外观模式
我们将一个系列相同的操作封装在一个遥控器中，简化操作。外观模式遵循的是最少知识原则将关联密切的函数一起使用，尽量减少对象之间的交互。
10.模板模式
将一系列算法的步骤或者流程封装在一个 方法，将相同的步骤实现，不同的步骤抽象
11.迭代器模式 iterator
12.组合模式
组合模式：将对象聚合成树形结构来表现“整体/部分”的层次结构，
组合模式能让客户以一致 的形式处理对象或者对象组合
也就是我们可以忽略对象组合与个体对象的差别
13.状态模式
14.代理模式
首先通过定义一个需要执行方法的借口
服务类注册和远程代理
客户端类寻找远程代理
最后管理类管理多个远程代理，管理多个对象。
15.复合模式
多个模式通常一起使用，组合在一个设计方案中
MVC复合模式：
MVC：Model、View、Controller
Model：是程序主体，代表了业务数据和业务逻辑
View：是与用户交互的界面，显示数据、接收输入，但不参与实际业务逻辑
Controller：接收用户输入，并解析反馈给Model
MVC里的模式：Model与View和Controller是观察者模式
View以组合模式管理控件
View与Controller是策略模式关系， Controller提供策略
16.桥接模式
将实现与抽象放在两个不同的类层次中，使两个层次可以独立改变
系统有多维角度分类时，而每一种分类又有可能变化，考虑使用桥接模式
桥接的目的是分离抽象与实现，使抽象和实现可以独立变化。
17.生成器模式（builder）
封装一个复杂对象构造过程，并允许按步骤构造。
java中的StringBuilder也是通过生成器模式设计的
18.责任链模式
如果有多个对象都有机会处理请求，责任链可使请求的发送者和接收者解耦，请求沿着责任链传递，直到有一个对象处理了它为止。
优点：
将请求的发送者和接收者解耦，使多个对象都有机会处理这个请求
可以简化对象，因为它无须知道链的结构
可以动态地增加或删减处理请求的链结构
缺点：
请求从链的开头进行遍历，对性能有一定的损耗
并不保证请求一定被处理
19.蝇量模式
通过共享的方式高效地支持大量细粒度的对象。
蝇量模式:蝇表示小，细粒的，量则是大量，大量的细粒的对象。
一个完整的蝇量模式可以容纳不同的对象并且显示，而且内存相比第一个传统的也要减少不少。
优点：
减少运行时的对象实例个数，节省创建开销和内存
将许多“虚拟”对象的状态集中管理
缺点：
系统设计更加复杂
需要专门维护对象的外部状态
适用场合：
需要大量细粒度对象
这些对象的外部状态不多，也就是我们例子中的属性。
按照内部状态分成几个组，每一个组都仅用一个蝇量对象代替
20.解释器模式：
定义一个语法, 定义一个解释器，该解释器处理该语法句子
将某些复杂问题，表达为某种语法规则，然后构建解释器来解释处理这类句子
优点：
容易修改，修改语法规则只要修改相应非终结符即可
扩展方便，扩展语法，只要增加非终结符类即可
缺点：
对于复杂语法的表示会产生复杂的类层次结构，不便管理和维护
解释器采用递归方式，效率会受影响
注意事项：
尽量不要在重要的模块中使用解释器模式
解释器模式在实际的系统开发中使用的非常少
可以考虑一下Expression4J、MESP、Jep等开源的解析工具包
适用场合： 当你有一个简单语法，而且效率不是问题的时候 一些数据分析工具、报表设计工具、科学计算工具等
21.中介者模式
用一个中介对象来封装一系列的对象交互。
中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互
优点：
通过将对象彼此解耦，可以增加对象的复用性
通过将控制逻辑集中，可以简化系统维护
可以让对象之间所传递的消息变得简单而且大幅减少
提高系统的灵活性，使得系统易于扩展和维护
缺点：
中介者承担了较多的责任，一旦中介者出现了问题，整个系统就会受到影响
如果设计不当，中介者对象本身变得过于复杂
适用场合： 一组对象之间的通信方式比较复杂，导致相互依赖，结构混乱
一个对象引用很多其他对象并直接与这些对象通信，导致难以复用该对象
中介者模式与外观模式：中介者模式注重的是内在的状态变化，而外观模式是注重的是外在的变化。
中介者模式和观察者模式：两者看起来很相似，都是通过注册然后去实现相应的行为，但是观察者模式实现的行为是固定的，而中介者模式需要实现的操作往往是需要变化的。
22.备忘录模式
在不破坏封装的前提下，存储关键对象的重要状态，从而可以在将来把对象还原到存储的状态。
优点：
状态存储在外面，不和关键对象混在一起，这可以帮助维护内聚
提供了容易实现的恢复能力
保持了关键对象的数据封装
缺点：
资源消耗上面备忘录对象会很昂贵
存储和恢复状态的过程比较耗时
注意事项： 注意开销
适用场合：
必须保存一个对象在某一个时刻的(整体或部分)状态，在对象以外的地方, 以后需要时恢复到先前的状态时
23.原型模式
通过复制现有实例来创建新的实例，无须知道相应类的信息。
优点：
使用原型模式创建对象比直接new一个对象更有效
隐藏制造新实例的复杂性
重复地创建相似对象时可以考虑使用原型模式
缺点：
每一个类必须配备一个克隆方法
深层复制比较复杂
注意事项： 使用原型模式复制对象不会调用类的构造方法。所以，单例模式与原型模式是冲突的，在使用时要特别注意。
适用场合：
复制对象的结构与数据
希望对目标对象的修改不影响既有的原型对象
创建对象成本较大的情况下
24.访问者模式
对于一组对象，在不改变数据结构的前提下，增加作用于这些结构元素新的功能。
适用于数据结构相对稳定，它把数据结构和作用于其上的操作解耦，使得操作集合可以相对自由地演化
优点：
符合单一职责原则
扩展性良好
有益于系统的管理和维护
缺点：
增加新的元素类变得很困难
破坏封装性
注意事项： 系统有比较稳定的数据结构
与迭代器的关系：在迭代器模式中我们也是遍历许多对象，但是在迭代器模式中我们并不需知道每个对象需要具体的操作。
适用场合： 如果一个系统有比较稳定的数据结构，又有经常变化的功能需求，那么访问者模式就是比较合适的
25.设计模式总结
模式：在某些场景下，针对某类问题的某种通用解决方案
场景：项目环境
问题：约束条件，项目目标等
解决方案：通用、可以复用的设计，解决约束，达到目标
设计模式的三个分类：
1.创建型模式：对象实例化的模式，创建型模式解耦了对象的实例化过程
2.结构型模式：把类或对象结合在一起形成更大的结构
3.行为型模式：类和对象如何交互，及划分责任和算法
设计模式的六大原则：
1 组合复用原则
多用组合，少用继承
找到变化部分，抽象，封装变化
区分“Has-A”与“Is-A”如果HasA表示你有它应该使用组合，IsA表示你是它应该使用继承。
2 依赖倒置原则
依赖：成员变量、方法参数、返回值
要依赖于抽象，不要依赖于具体
高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖具体，具体应该依赖抽象
针对接口编程，不要针对实现编程
以抽象为基础搭建的结构比具体类搭建的结构要稳定的多
在java中，抽象指的是接口或者抽象类，具体就是具体的实现类
3 开闭原则
对扩展开放，对修改关闭
通过扩展已有软件系统，可以提供新的功能
修改的关闭，保证稳定性和延续性
4 迪米特法则
一个对象应该与其他对象保持最少的了解。只与直接朋友交谈。
成员变量、方法参数、方法返回值中需要的类为直接朋友
类与类之间的关系越密切了解越多，耦合度越大
尽量降低类与类之间的耦合
外观模式、中介者模式
接口隔离原则：一个类对另一个类的依赖应该建立在最小的接口上
5 里氏替换原则
所有引用基类的地方必须能透明地使用其子类对象
子类在扩展父类功能时不能破坏父类原有的功能
使用继承时，遵循里氏替换原则：
子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
当子类重载父类方法时，方法的形参要比父类方法的参数更宽松
当子类实现父类的抽象方法时，方法的返回值要比父类更严格
里氏替换原则是设计整个继承体系的原则
6 单一职责原则
类应该只有一个导致类变更的理由
即一个类只负责一项职责
降低类的复杂度
提高系统的可维护性
修改时降低风险溢出
