责任链模式
定义:使多个对象都有机会处理请求,从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链。并沿着这条链传递该请求,直到有对象处理它为止。
责任链模式的通用代码
public abstract class Handler{
private Handler nextHandler;
//每个处理者必须对请求做出处理
public final Response handleMessage(Request request){
Response response = null;
if(this.getHandlerLevel().equals(request.getRequestLevel())){
reponse = this.echo(request);
}else{
if(this.nextHandler != null){
response = this.nextHandler.handleMessage(request);
}esle{
//没有适当的处理者,业务自行处理
}
}
return response;
}
//设置下一个处理者是谁
public void setNext(Handler _handler){
this.nextHandler = _handler;
}
//每个处理者都有一个处理级别
protected abstract Level getHandlerLevel();
//每个处理者都必须实现处理任务
protected abstract Response echo(Request request);
}
public class ConcreteHandler1 extends Handler {
protected Response echo(Request request) {
//定义自己的处理逻辑
return null;
}
protected Level getHandlerLevel() {
//设置自己的处理级别
return null;
}
}
public class ConcreteHandler2 extends Handler {
protected Response echo(Request request) {
return null;
}
protected Level getHandlerLevel() {
return null;
}
}
public class ConcreteHandler3 extends Handler {
protected Response echo(Request request) {
return null;
}
protected Level getHandlerLevel() {
return null;
}
}
public class Level{
//定义级别
}
public class Response{
//封装处理结果
}
public class Request {
//封装请求参数
//返回处理级别
public Level getRequestLevel(){
return null;
}
}
在实际应用中,一般有一个封装类对责任模式进行封装,也就是替代Client类。直接返回链中第一个处理者。具体链的设置不需要高层次模块关系。
优点:将请求和处理分开。请求者可以不用知道是谁处理的,处理者也可以不用知道请求的全貌。两者解耦,提高系统的灵活性。
缺点:性能问题,每一个请求都是从链头遍历到结尾,特别是链条比较长,环节比较多的时候。调试不方便,比较复杂,特别是链条比较长的时候。
注意:避免出现超长链的情况,一般的做法是在Handler中设置一个最大节点数量。在setNext方法中判断是否已经是超过其阈值。超过则不允许该链建立。
最佳实践:
Handler抽象类完成了请求传递的功能,子类实现请求的处理。符合单一职责原则。屏蔽了请求的处理过程,只要把请求抛给责任链模式的第一个处理者,最终会返回一个处理结果。作为请求者可以不用知道到底是谁来处理的。这是责任链模式的核心。
装饰模式
定义:动态的给一个对象添加一些额外的职责。就增加功能来说,装饰模式相比生成子类更为灵活。
有四个角色需要说明:
1. Component:是一个接口或者是抽象类。就是定义我们最核心的对象,也就是我们最原始的对象。
2.ConcreteComponent:具体构件。是Component的实现类。要装饰的就是他。
3. Decorator:装饰角色。一般是一个抽象类。他不一定有抽象方法,在他的属性里必须有个private变量指向Component抽象构件。
4. 具体抽象角色:把最核心的、最基本的东西装饰成其他东西。
通用代码如下:
public abstract class Component {
public abstract void operate();
}
public class ConcreteComponent extends Component {
@Override
public void operate() {
System.out.println("do Something");
}
}
public abstract class Decorator extends Component {
private Component component = null;
//通过构造函数传递被修饰者
public Decorator(Component _component){
this.component = _component;
}
//委托给被修饰者执行
@Override
public void operate() {
this.component.operate();
}
}
public class ConcreteDecorator1 extends Decorator {
//定义被修饰者
public ConcreteDecorator1(Component _component){
super(_component);
}
//定义自己的修饰方法
private void method1(){
System.out.println("method1 ÐÞÊÎ");
}
//重写父类的operate方法
public void operate(){
this.method1();
super.operate();
}
}
public class ConcreteDecorator2 extends Decorator {
public ConcreteDecorator2(Component _component){
super(_component);
}
private void method2(){
System.out.println("method2ÐÞÊÎ");
}
public void operate(){
super.operate();
this.method2();
}
}
//原始方发和修饰方法的执行顺序在具体的装饰类是固定的。可以通过方法重载实现多种执行顺序。
public class Client {
public static void main(String[] args) {
Component component = new ConcreteComponent();
//第一次修饰
component = new ConcreteDecorator1(component);
//第二次修饰
component = new ConcreteDecorator2(component);
//修饰后运行
component.operate();
}
}
优点:
1。装饰类和被装饰类可以独立发展,而不会相互耦合。- 装饰模式是继承关系的一个替代方案。我们看装饰类,不管修饰多少层,返回的对象还是Component.
- 可以动态地扩展一个实现类的功能。
缺点:多层的修饰模式是比较复杂的。就像剥洋葱一样,剥到了最后才发现最里层的装饰出现了问题。所以尽量减少装饰类的数量。以便降低系统的复杂度。
使用场景:- 需要扩展一个类的 功能,或给一个类增加附加功能。
- 需要动态的给一个对象增加功能,这些功能可以动态的撤销。
- 需要为一批的兄弟类进行改装或加装功能,当然是首选装饰模式。
最佳实践:继承可以扩展类的功能,但是难维护,难扩展,难复用等。而且继承可能导致类膨胀.继承时静态的给类增加功能,而装饰模式则是动态的增加功能,扩展性好。
策略模式
定义:定义一组算法,将每个算法都封装起来,并且使他们之间可以互换。
三个角色:
1. Context封装角色:上下文角色,起承上启下封装作用,屏蔽高层模块对策略、算法的直接访问,封装可能存在的变化。
2. Strategy抽象策略角色
3. ConcreteStrategy:具体策略角色。
通用源码:
public interface Strategy {
//策略模式的运算法则
public void doSomething();
}
public class ConcreteStrategy1 implements Strategy {
public void doSomething() {
System.out.println("具体策略模式1运算法则");
}
}
public class ConcreteStrategy2 implements Strategy {
public void doSomething() {
System.out.println("具体策略模式2运算法则");
}
}
public class Context {
//抽象策略
private Strategy strategy = null;
//构造函数定义具体策略
public Context(Strategy _strategy){
this.strategy = _strategy;
}
//封装后的策略方法
public void doAnythinig(){
this.strategy.doSomething();
}
}
public class Client {
public static void main(String[] args) {
//声明一个具体的策略
Strategy strategy = new ConcreteStrategy1();
//声明上下文对象
Context context = new Context(strategy);
//执行封装后的方法
context.doAnythinig();
}
}
- 优点:
- 可以自由切换。
- 避免使用多重条件判断。
- 扩展性良好。
- 缺点:
1.类数量增多
- 所有的策略类都需要对外暴露。上层模块必须知道有哪些策略。然后才能决定使用哪一个策略。我们可以使用其他模式来修正这个缺陷。如工厂方法模式、代理模式或享元模式。
使用场景:
- 多个类只有在算法上或行为上稍有不同的场景。
- 算法需要自由切换的场景
- 需要屏蔽算法规则的场景
注意事项:如果策略超过四个,则考虑使用混合模式,避免类膨胀和对外暴露的问题。
策略模式的扩展:策略枚举
定义:它是一个浓缩了策略模式的枚举。
public enum Calculator {
ADD("+"){
public int exec(int a,int b){
return a+b;
}
},
SUB("-"){
public int exec(int a,int b){
return a - b;
}
};
String value = "";
private Calculator(String _value){
this.value = _value;
}
public String getValue(){
return this.value;
}
public abstract int exec(int a,int b);
}
public class Client {
public static void main(String[] args) {
int a = Integer.parseInt(args[0]);
String symbol = args[1];
int b = Integer.parseInt(args[2]);
System.out.println("输入的参数为"+Arrays.toString(args));
System.out.println("运行结果为"+a + symbol + b + "=" + Calculator.ADD.exec(a, b));
}
}
注意:策略枚举模式受枚举类型的限制,每个枚举值都是pulic static final,扩展性受到了一定的约束。因此策略枚举一般担当不起经常变化的角色。