需要的技术能力

1，对于基础的设计模式有一定了解，例如工厂和策略

2，有一定代码基础

文章主体开始

基础知识

无

杜撰的需求背景

（由于不能够将需求直接写在网络上，那么我们假设了一个脱离现实的情况）

爬虫爬到了一批数据，数据有不同的厂家，每个厂家有不同的处理方式，不同的厂家对于不同的商品，有不同的打折方式

打折方式说明：买多少件可以打折，买一定的数量可以继续打折，例如1000件变九折，2000件变八折，以此类推，几折封顶，那么那怕你买10亿件，也是这个封顶的折数

厂家1：

产品1：价格默认是100块钱，买1000件开始可以打九折，最高九折，厂家信息，厂家地址，等等其他信息忽略

产品2：价格默认是1000块钱，买1000件开始可以打九折，最高九折，厂家信息，厂家地址，等等其他信息忽略

厂家2

产品3：价格默认是700块钱，买1000件开始可以打九折，最高九折，厂家信息，厂家地址，等等其他信息忽略

产品4：价格默认是10000块钱，买1000件开始可以打九折，最高九折，厂家信息，厂家地址，等等其他信息忽略

厂家3

产品5：价格是500块钱，买1000件可以九折，2000件八折，3000件七折，4000件六折，5000件五折，最高五折，厂家信息，厂家地址，等等其他信息忽略

产品6：价格是10000块钱，买1000件可以九折，3000件八折，5000件七折，最高七折，厂家信息，厂家地址，等等其他信息忽略

厂家5，.。。。。

厂家6，.。。。。。。

描述还是不怎么对，但是将就看吧

版本1

我们可以简单的设计一下，每个产品和处理方式都有自己的关系，那么工厂和策略简直是完美方案

写一个接口，作为处理方式的父类，他的子类都是每个处理方式的实现类（策略设计模式）

写一个工厂，在工厂里面维护每个产品对应的处理方式

那么我们在使用的时候，直接可以通过工厂，入参为产品id，拿到处理方式的实现类

扩展思考

假如后续要继续增加厂家或者产品，直接在工厂维护产品id和处理方式的对应关系，以及处理方式由于新增了产品id需要重新新增一个实现类

版本1的缺陷

1，产品会越来越多，处理方式的实现类是不是越来越多了？

2，这样子是不是耦合度很高，不利于后续扩展？

3，想一想上面的处理方式很多地方是不是共用的，能不能将多个处理方式合并归类，抽取成为同一个

版本1缺陷的解决方案

在产品id和处理方式中间，再加一层，作为规则层

版本2

新增规则的概念，每个产品id只是对应一个规则，每个规则都有自己的实现类，为同一类产品id进行服务

(以下名字为临时使用，请不要这么写，会对项目产生困扰)

维护一个RuleRequest对象

public class RuleRequest {
    // 当前的请求是哪个规则
    private SqlRuleEnum sqlRuleEnum;
    // 规则对应的处理信息
    private Map<String, Set<Double>> ruleMap;
    // 特殊的请求信息
    private Map<String, Object> requestMap;
}

维护一个规则的枚举

public enum SqlRuleEnum {
    RULE_ONE(1, "处理方式1"),
    RULE_TWO(2, "处理方式2"),
    RULE_THREE(3, "处理方式3"),
    ;
}

其他

vx公众号：Java雪糕