因为设计模式————加班14天，没写出来一个需求

这几天在美团加班了14天，没写出来代码。不解释，纯菜。

适配器模式

我有一个非常简单的需求：更新一个字段。有人说：那还不简单，一个update直接解决啊。你菜就直说，别绕弯子。

这时候。就遇见了第一个问题：适配器模式。

美团有两个不同的公司：美团、大众点评。他们底层代码是不一致的。我上线的所有功能，当我更新的时候，美团开始售卖，大众点评也开始售卖。

如何实现？适配器模式。

我更新了以后，通过适配器模式实现两个不同的变更。不需要同时改动美团和大众点评的代码

所以，我只能调用提供的接口来进行变更。

我不能直接操作数据库，我需要操作适配器

通过适配器来调整参数。

策略模式

然后就出现了第二个问题：美团有版本1.0和版本2.0

美团有版本1.0、版本2.0，同时还得更新大众点评。于是我们就可以了解这个项目的全貌了：

通过策略模式，来控制流量走哪个接口
然后通过适配器模式，来同时更新美团和大众点评

于是大聪明就出现了：

先通过策略模式实现流量的转发，控制1.0还有2.0
然后再通过策略模式实现业务的切换
最后通过适配器实现双端售卖

策咯模式套策略模式套适配器模式

但是有个问题我得给你聊：美团有个业务，他数据量太大了，底层数据库扛不住。

那咋办？我有个建议：上es。

双写，然后读es。

太简单了：实现一个策略模式，读取es和mysql

于是大聪明就出现了：策略模式大聪明已经看懂了：

通过策略模式实现流量的转发，控制1.0还是2.0
然后通过策略模式实现业务的切换
在业务中，实现策略模式，实现es和mysql的双写

DDD解耦方式

而这个逻辑，被封装进了一个服务中。

人话：通过微服务进行aop切面

我调用某个服务
服务给你构建上下文，然后将新的上下文传给你
你基于这个服务实现切面

我们可以通过一个统一的上下文，来管理策略的控制。 ×　　你传入一个特定的参数，我们通过参数来控制上下文，来实现策略的转发

好消息好消息：我开发的需求正好击穿了上下文模式。

你看：我传入了一个上下文，他是用来实现策略模式的。但是问题是：我的场景没办法传入上下文。

我新接入了一个业务方，想要接入这个，需要单独的给这个业务方构建上下文。但是：请问构建上下文的微服务是哪个？

线程安全 + 重试

然后我们继续聊：上下文模式需要传入上下文，但是上下文有线程安全问题。

原因也非常简单：

我的接口有性能问题，必须使用多线程
而多线程不能共享一个上下文

我复述一下这个问题：

一个接入方，他必须使用统一的上下文
但是我这个接入方，他需要可变上下文
但是我有线程安全问题，所以必须单独构建上下文

if

我很生气，于是我就开始写if分支了。我不传上下文，我直接手写if else不行？

然后主R表示：你这样无法维护，没法下线

你得实现策略模式，依赖美团实现的策略模式套策略模式，实现策略模式

然后我就凉凉了。

学不会？

简单来说，滥用了策略模式，导致学习成本极高。不用策略模式，开发成本也极高