设计模式-策略模式

最新推荐文章于 2024-08-06 19:20:31 发布

wait_for_eva

最新推荐文章于 2024-08-06 19:20:31 发布

阅读量165

点赞数

分类专栏：设计模式

本文链接：https://blog.csdn.net/wait_for_eva/article/details/106850086

版权

设计模式专栏收录该内容

27 篇文章 1 订阅

订阅专栏

策略模式

策略模式是啥，就是选择，或者说是操作的选择。

def calc(operation, a, b):
  if operation == "add":
    return a + b
  elif operation == "sub":
    return a - b
  elif operation == "mul":
    return a * b
  elif operation == "div":
    return a / v
  raise Exception(f'unknow operation : {operation}')

这是最简单的例子，写法上没有问题，但是实际场景下面，这几点不得不说

判断冗余

太多的分支判断，判断参数被重复的使用。

操作复杂

很多情况下，操作并不是简单的一两句话，如果全部陈列，代码不可谓优美。

维护性差

如果想要增加新的选项，居然还要去改动原来的代码。

基于以上原因，总结规律之后发现，我们可以这样做

操作包装

首先，把操作进行包装成方法，方便调用。

直接选择

避免重复条件对比，直接指定operation，而非逐个进行对比，采用hash直接选取操作。

动态注册

这个就是额外的点了，本身并不包含在策略模式之内，但是如果有个归纳的容器，更好的管理就更好了。

初始问题

def calc(a, b):
  return a + b

最初情况下，计算的场景只是包含add。

这种场景下，新增计算方式，不仅要新增代码，还需要修改其他计算无关部分，甚至项目结构。

于是，变成了最上面的方式。

不过问题还在，还是需要去修改原来的代码，即使每个分支的操作封装成了方法。

同时，也还算不上是策略模式，策略模式最关键的在于

相同的概念，各种具体方式的选择。

也就是说，虽然叫做calc，但是具体操作的时候，我必定明确了到底是哪一种操作。

这种直接遍历，说实话，太糟糕。

策略实现

def add(a, b):
  return a + b

def div(a, b):
  if b == 0:
    raise Exception("div by zero")
  return a / b

def calc(operation, a, b):
  return operation(a, b)


calc(add, a, b)

这样一来，的确称得上是策略模式了，或者通俗一些，应该称作内核替换。

不管是交通、吃饭还是什么，它确切的存在一个场景，一个概念，但是落实的时候，具象化的现实是独一无二的。

所以具体的就会知道交通是火车、汽车还是轮船，饭是老干妈鸡蛋还是老干妈鸡蛋还是老干妈鸡蛋。

在关键处留白，留下一个占位，简历流程上的完整性，但是忽略具体的操作，仅仅留下一个可操作方法。

通过外部去指定，去传入这个方法，从而达到流程化中的细节替换。

我们可以搭建一条流水线去解决一类的问题，而不能为了解决一个问题而搭建一条流水线。

通过这种方式，可以保证一类操作流程上的相似性，而差异化的部分通过补丁来进行修正。

标准实现

接口

public interface CalcStrategy{
  public double calc(double a, double b);
}

场景(上下文)

public class Context{
  double a;
  double b;
  double result;
  
  public void setParams(double a, double b){
  	this.a = a;
    this.b = b;
  }
  
  private void before(){
    System.out.printf("a = %s, b = %s\n", a, b);
  }
  
  private void after(){
    System.out.printf("result = %s \n", result)
  }
  
  public void dealWith(CalcStrategy calcStragegt){
    before();
    result = calcStragety(a, b);
    alter(result);
  }
}

策略

public class AddStrategy implement CalcStrategy{
  public double calc(double a, double b){
    return a + b;
  }
}

public class SubStrategy implement CalcStrategy{
  public double calc(double a, double b){
    return a - b;
  }
}

使用

public static void main(String [] args){
  Context ctx = Context();
  ctx.setParams(2, 1);
  ctx.dealWith(new AddStrategy());
}

注册

策略模式本身有个天然的缺点：默认你已经知道将要进行的具体操作。

这样一来，它的功用就是把原来复杂的为了进行逻辑兼容的分支。

对比一下工厂模式，你会发现两者都是一样的，就是既定场景的默认。

不过一个针对的操作，而一个针对的是对象。

同理，我们都可以使用外观模式进行统一。

public abstract AbstractCalcStrategy implements CalcStrategy{
  private final ConcurrentHashMap<String, CalcStrategy> calcStrategies = new ConcurrentHashMap<>();
  
  @PostConstruct
  public void init(){
    calcStragegies.put(getClass().getName(), this);
  }
  
  public CalcStrategy getStrategy(Class<? extends CalcStrategy> clazz){
    String name = clazz.getName();
    if (! calcStragegies.containsKey(name)){
      return null;
    }
    return strategies.get(name);
  }
}