Java 24 设计模式
一.策略模式(Strategy pattern)
1.策略的共同点抽象成接口，具体策略实现这个接口;
2.抽象一个策略接口的包装容器Context，里面包装策略的实现方法;
3.策略的具体执行类，负责策略的最终应用;
总结：
策略模式体现高内聚低耦合的特点，把具体策略类，策略共同点抽象出的接口，及策略的执行场景(上下文)，具体的策略执行类分开;
二.代理模式(Proxy pattern)
1.定义一类事物共同的特点(能执行的操作)抽象成接口
2.具体的事物类，实现这个接口，及具体执行的操作
3.如果其中一个事物类不能做这些事，可以将其定义成其他事物类的代理
4.定义成其他事物类的代理的类，要实现两个构造方法，一个是定义默认代理的事物类，一个是可以任意定义代理的事物类;实现以后的复用;
总结： 代理模式体现java的多态特性，代理类接到任务交给其他被代理的类去完成，前提是代理类和被代理类实现同一个接口；
三.单例模式(Singleton pattern)
1.类的构造方法是私有的
2.类中有一个获取类实例的静态方法
3.多线程情况还要考虑线程同步获取实例的方法
总结：
单例模式用在要且只要一个对象的类，保证类实例的唯一性；
四.多例模式（有上限的多例模式）(Mulition pattern)
1.类的构造方法是私有的
2.把获取实例的方法放在静态代码块中，把获取的实例放在List中
3.多线程情况很少
总结：
多列模式，但实例的数量有个上限，需要根据具体情况设置。
五.简单工厂模式(Simple factory pattern)
1.把要产生的类的共性抽象成一个接口
2.具体的类实现这个接口
3.写一个产生类的工厂方法
4.写一个利用工厂制造类的操作者类
总结：
简单工厂模式简化了生成具体对象，我们所需要的只需要修改对象对应的类的共同属性就可以实现，工厂类完成其他操作
六.抽象工厂模式(Abstract factory pattern)
1.定义最终目标类的共性成一个接口
2.定义要最终目标类的抽象类，实现目标类共性定义的接口
3.定义目标类中几个不同的属性的具体执行类继承对应的抽象类
4.根据工厂类最终要实现的方法，定义一个工厂类接口
5.定义一个包含通用方法的抽象类，实现工厂类接口
6.根据具体需要，创建具体实现工厂类，继承抽象类
总结：
工厂模式符合开闭原则(OCP)，在产品中增加一类产品，再增加一个工厂方法就可以了。
七.门面模式(Facade pattern)
1.根据处理某类事件的具体操作定义一个接口
2.定义一个具体实现上面接口的实现类
3.定义一个类把所有操作封装在一个方法里
4.定义一个需要这些操作的客户端
总结：
门面模式把一些复杂的操作封装起来，让用户感觉操作起来十分简便。如果操作流程改了，只需要改少量代码即可达到需求。
八.适配器模式(Adapter pattern)
1.定义一个适配者所有的操作接口
2.定义一个类实现这个适配者操作接口
3.定义一个被适配者所有操作的接口
4.定义一个类实现被适配者操作接口
5.定义一个连接两者的适配器
6.定义一个需要具体操作的类
总结：
适配器模式不适合在设计阶段使用，主要应用在扩展修改系统功能时使用，使用适配器模式减少原有系统代码修改。
九.模板模式(Template pattern)
1.定义一个顶级抽象类模型，包含基本方法和模板方法(基本方法的组合)
2.定义具体的对象模型类，继承顶级抽象模型类
3.定义执行操作类
总结：
模板方式在(struts2)应用挺多，提供一个抽象类，然后修改其protected方法，实现具体的功能，然后调用一个execute方法，完成操作。父类调用子类的方法，在项目中不建议使用
十.建造者模式(Builder pattern)
1.前一部分如同模板模式
2.根据实际需求创建一个建造者抽象类，定义建造者用到的方法
3.根据具体需要被造的物体设计对象制造者类，继承建造者抽象类
4.根据客户最终需要设计指导者类，确定具体建造流程
5.定义执行操作类
总结：
建造者模式适合产品类复杂繁多的情况，就是业务较复杂时。还有对象在创建过程中使用到其他不易得到的对象。
十一.桥梁模式(Bridge pattern)
1.定义一个最终目的产品抽象类，包含对应的抽象操作方法
2.定义最终产品类，继承上面的目的产品抽象类，重写抽象操作方法
3.定义一个负责生产最终目的产品的抽象公司类，包含公司类要实现的方法
4.定义生产具体产品的公司类继承抽象公司类，重写抽象公司类的方法
5.定义执行操作类
总结：
桥梁模式的优点是类间解耦，使类间的联系弱化。业务抽象角色引用业务实现角色
十二.命令模式(Command pattern)
1.根据命令的最终接受者执行的操作，定义抽象命令接收者命令
2.定义命令接收者类，继承上面定义的抽象类
3.定义命令抽象类，包含一个execute方法
4.定义具体的命令类
5.定义命令调度者类，接收命令并布置具体执行
总结：
命令模式具备很好的封装性，把命令的请求方和执行方分开了。但如果业务逻辑复杂，Command类会过于复杂，在实际项目中类会膨胀。
十三.装饰模式(Decorator pattern)
1.定义一个最原始的，被修饰的核心类
2.定义具体的被装饰的具体类，继承核心类
3.定义一个装饰抽象类
4.根据具体的被装饰类，定义装饰类
5.定义要查看最终被装饰产品的类
总结：
装饰模式是对继承的补充，装饰模式是给类动态的增加功能
十四.迭代器模式(Iterator pattern)
1.定义一个具体项目迭代器接口继承java.util.Iterator类
2.定义一个项目使用的迭代器类，实现上面那个接口
3.定义有一个对项目的操作接口
4.定义具体的项目操作类实现上面的接口
5.定义项目的最终操作类
总结：
Java已经把迭代器给我们准备好了，项目很少再独立写迭代器了，直接用List或Map就可以解决问题。
十五.组合模式(Compsite pattern)
1.定义一个实现所需功能的抽象类
2.根绝具体所需生成的对象定义类，继承上面的抽象类
3.定义跟节点类，及接口
总结：
组合模式分为安全模式和透明模式，提供一套组合方法，适合树形结构或者局部与整体的关系。
十六.观察者模式(Observer pattern)
1.定义一个被观察者实现Observable接口。
2.观察者实现Observer接口。
3.操作类实现具体操作
总结：
观察者和被观察者自己没有任何联系，方便以后的扩展和维护。
十七.责任链模式(Chain of Responsility pattern)
1.根据请求对象的属性，定义一个接口
2.定义具体的请求对象类
3.根据请求处理者类抽象一个Handler类
4.定义具体的请求处理者类，继承上面的抽象类
总结：
责任链模式是请求者不必考虑谁是处理者，只要请求发出，就会有处理者，Handler的子类可以继续增加下去。调用者不用了解变化过程。
十八.访问者模式(Visitor pattern)
1.定义一个访问者超级接口
2.定义具体的访问者接口，包含访问者要实现的方法
3.定义具体的访问者实现类
4.定义被访问的对象的抽象类
5.实现具体的被访问对象继承上面的类
6.执行操作类
总结：
访问者模式是访问者对象和被访问者对象隔离，根据访问者模式能实现简单的Interceptor
十九.状态模式(State pattern)
1.定义要表示的对象抽象出来的接口
2.定义具体的对象类，实现上面定义的接口
3.定义对象状态的抽象类
4.定义对象处于的环境上下文类
5.定义对象会处于的具体状态类
6.客户端执行类
总结：
状态模式，当一个对象内在状态改变时，允许其改变行为，看起来好像对象对应的类发生了改变，但子类会太多。
二十.原型模式(Prototype pattern)
1.写一个要被创建的对象类的模板类
2.定义要被clone的对象类
3.客户端执行操作
总结：
原型模式是对通过对已有对象的拷贝创建新对象。既能节约硬件资源也能有效保护元对象不被修改。
二十一.中介者模式(Mediator pattern)
1.定义抽象的中介者类，具体的中介者去继承这个类
2.定义中介这要协调的同伴类
3.定义要执行具体操作的类
4.客户端调用执行
总结：
中介者模式实现很好的封装，是类间的依赖减少。
二十二.解释器模式(Interpreter pattern)
1.声明一个表达式都要实现的抽象类，包含interpret()方法
2.具体的表达式类，继承上面的抽象类，实现具体的方法
3.表达式运行的上下文环境类
4.客户端调用执行类
总结：
定义一个语句，解释器模式可以定义出其文法的一种表示，并提供一个解释器，客户端可以利用解释器来解释这个语句。
二十三.亨元模式(Flyweight pattern)
1.定义只有内蕴状态的类，内蕴状态不会改变可以共享
2.定义含有外蕴对象的类，外蕴状态会随环境改变而改变，不可以共享
3.单纯亨元模式和符合亨元模式
总结：
亨元模式可以有效降低内存中对象的数量，但会使系统变复杂，将亨元对象的状态外部化，读取外部状态的时间会变长。
二十四.备忘录模式
1.定义一个备忘录类接口，起标识作用
2.定义一个备忘录类，保存状态信息
3.定义一个发起者，负责改变状态
总结：
备忘录模式，可以有效恢复对象的状态。在不破坏封装的前提下，将对象的状态捕捉。
Java 6个设计原则
一.单一职责原则
接口做到单一职责，一个接口定义一类方法属性，类尽量只有一个原因引起变化。
二.里氏替换原则
里氏替换原则目的是加强程序的健壮性，在版本升级时可以做到非常好的兼容性，一个类的修改，不会影响其他类的正常运行。
三.依赖注入原则
把各个类间的依赖关系交给第三方进行管理，类间没有直接的依赖关系，或依赖很弱，调用者不需要考虑类之间的依赖关系，后期对项目的维护也会相对简单。这样这些就实现了高内聚低耦合。
四.接口隔离原则
根据接口隔离原则拆分接口时，必须满足单一职责原则。接口隔离原则实现高内聚，并可提供定制化服务
五.迪米特法则
出现在成员变量，方法的输入输出参数中的类被称为成员朋友类，一个类只和朋友类交流。
对外公布尽量少的public方法和非静态的public变量，尽量内敛,如果能设置成最终不可改变，尽量就加上final关键字，如果方法放在本类中，既不增加类间关系，对本类不产生负面影响，就放置在本类中
六.开闭原则
一个软件应该对扩展开放，对修改关闭，保证模块在不被修改的前提下被扩展。满足可复用和易维护，核心是抽象一个事物。