业务背景

这个服务对应下图中的广告主server的接口一,一般业内叫监测链接,是一种回调链接,用于用户点击广告,媒体平台通过这个接口通知给我们这样的广告主。

这个业务之前使用php写的,因为初创,工期紧,当时编码人员也是首次接触该业务,对业务特点理解不深入等原因。

导致旧系统具有以下特点:

1.旧系统是纯粹的过程式编码方式,每对接一个新的渠道,就要完全新开发一个渠道代码。

2.在阅读旧代码的过程中,可以很明细的意识到所有渠道的业务处理流程都都是相似的N个步骤,不同渠道间的变化点在于:具体的每个步骤细节有差异。

3.整个业务处理的输入是不同, 数据处理的步骤是相似的, 输出都是构成1个Dao结构体,然后把Dao写表。

经过梳理和分析,我们找到一些变与不变的东西:

1.不同渠道业务具有相似的部分:处理步骤的相似,并且不同步骤没有必然的顺序依赖。

2.不同渠道的变化点在于每个步骤的具体细节不同。

3.所有渠道的输出都是相同的:构造1个Dao结构体。

新设计期望达到的效果

便于维护

1.对接新的广告渠道时,尽可能的能复用,只对接每个步骤的细节部分,主体的步骤顺序不变。

2.同事之间交接服务的时候,也更方便同事迅速看出主要设计，get核心业务点, 明确变化点。

针对业务特点进行设计

1. 通过接口来实现约束相似的步骤

2. 通过接口方法的不同实现,来应对步骤内部具体细节的变化

这样设计,是从业务出发,而不是为了硬套设计模式。

设计完成之后,发现这个设计基本就是代理模式,于是调整一些命名,显示的体现这个模式在项目中的应用。

本次设计重构的心得

1.是结合业务特点,找到其中不变和变的部分，然后想办法用接口来承接这个不变的部分，用多态来封装变化的部分。

2.不要用设计模式去套业务,生搬硬套的做法不利于提高自身的软件设计能力。偶尔碰对了,也只是运气。逐步推理出的设计会更好,哪怕这个设计没有名字,也是好的设计。

3.适当考虑和同事讨论设计。 一方面,讨论设计是一个让人愉快,也有意思的事情。另一方面,我最开始和leader讨论,在讨论的过程可以逐渐明确变与不变的东西,同时也能保证目标和leader偏差不大。

代理模式的模版

TODO

代理模式在本次重构中的实现

TODO

20210728-彩蛋

非常尴尬,经过和同事讨论,这个模式实际上是模板方法,而不是代理模式。 不过具体叫什么模式不是主要的,重要的是,能够识别出变和不变的地方,并知道如何利用接口,多态等编程元素来提取不变的东西和封装变化的东西

另外整个项目设计还进行的一些改变。

因为分层之后,什么逻辑应该放哪一层,没有梳理得很清楚,导致一些不太好的地方。

这个之后我再梳理一下。// TODO

附录

1.Go设计模式06-代理模式(generate实现类似动态代理)

2.Go 实现常用设计模式（九）代理模式