EliteQ(87***60) 15:26:06
一个销售系统，有多种前端，PC/手机/微信， 若需要根据渠道统计销量， 这个销售系统该如何设计渠道的收集功能，
a. 设计一个方法给各个前端调用 ，该方法包含一个参数，名为i渠道代号，各前端调用时给出。
b. 为每一种前端设计一个方法，特定的前端调用特定的方法。
c. 其它
真心求教。
涂文军(20***77) 15:27:08
a好些吧
EliteQ(87***60) 15:29:02
但是A的话，会不会有作假？ 各前端不老实调用
EliteQ(87***60) 15:29:23
比如明明是PC, 却传入微信的渠道代号
上郭智超(46***588) 15:32:43
那给各个渠道一个方法呢？
上郭智超(46***588) 15:33:16
pc指导到pc调用的方法，微信只知道微信调用的方法
EliteQ(87***60) 15:36:57
对，b选项就是这个意思。但是，感觉也不是很科学，岂不是多一个渠道 就要加多一个方法
EliteQ(87***60) 15:37:20
所以才有 c 选项，想听听各位大牛的意见
上郭智超(46***588) 15:42:02
我也听听，我觉得B好些。不应该把最通用的方法暴露出去，不小心参数写错了，也麻烦。为每个独立的业务做个独立的方法
成殷小华(114***47) 15:51:49
你那接口得看是提供给外部系统用还是自己用吧。
张攀(369***82) 15:52:10
大家的瓶颈 都不在设计 尽管设计可能也有很大改进空间 但是需求技能提升更着急些
Z(520***504) 15:53:10
我着急的是分析和设计
成殷小华(114***47) 15:53:17
需求直接关系到客户利益。 ，设计没得这么强烈。
EliteQ(87***60) 15:53:54
@jeffrey 如果是对内和对外都需要提供接口呢
EliteQ(87***60) 15:55:31
内部系统 有PC/手机/微信 三种接入前端。 如果有一天对外开放了， 外部系统也有 PC/手机/微信 3种接入前端， 这个渠道的接口该怎么设计会比较好呢
上龚智勇(80**736) 15:56:34
@EliteQ(87***60) 需要把你的需求描述完整。
上龚智勇(80**736) 15:56:57
如果只收集销量，你的方案就可行
上龚智勇(80**736) 15:57:15
如果还要防错调，漏调
上龚智勇(80**736) 15:57:34
这个要看看是不是一个接口方案能解决的
EliteQ(87***60) 15:57:40
但问题我觉得不够好啊，如果是b方案，岂不是加一个渠道，我就要上线一个新接口？
上龚智勇(80**736) 15:57:59
你可以约定参数不同啊
EliteQ(87***60) 15:58:16
如果是 a 方案，如果错调呢
EliteQ(87***60) 15:58:42
大家除了这2个方案，就没有其它方案了吗？
上龚智勇(80**736) 15:58:58
错调怎么搞啊，你让他们注册，绑定IP，就是把流程搞复杂点
上龚智勇(80**736) 15:59:07
绑定域名等等
上龚智勇(80**736) 15:59:28
错了就不通，不通就会漏
EliteQ(87***60) 15:59:40
要搞这么复杂吗？我只想求第3方案，不知道有没有
EliteQ(87***60) 16:00:04
没有，再考虑回前2个方案
上龚智勇(80**736) 16:00:10
你的2个满足你的需求了吗？
上龚智勇(80**736) 16:00:27
如果没满足，你的需求描述完整了吗？
EliteQ(87***60) 16:00:31
满足啊，只不过我觉得弹性不够好
EliteQ(87***60) 16:00:48
扩展成本比较高
上龚智勇(80**736) 16:00:59
觉得弹性不好是因为要再开发个接口？
EliteQ(87***60) 16:01:12
是
EliteQ(87***60) 16:01:35
我想知道有没有更优的选择
上龚智勇(80**736) 16:01:52
那一般就是增加参数，改成配置
EliteQ(87***60) 16:01:52
关于收集渠道的需求，大家都是这样设计的么？
上龚智勇(80**736) 16:02:46
很多开放平台的api你研究下，他们接入的可比你这个多
上龚智勇(80**736) 16:03:10
一般对外的接口就一个
成殷小华(114***47) 16:03:14
外部接口的话提供统一接口好点，提前约定规范。
成殷小华(114***47) 16:03:58
扩展的时候外部接口规范不变，内部扩展就行。
EliteQ(87***60) 16:05:11
那就是选a?
京王明云(23***97) 16:05:39
应该选择方案b。方案a的扩展性差，不灵活。微信、手机、PC的接口实现方式分分钟可能会发生不同。
成殷小华(114***47) 16:05:54
要不然你以后更新版本多老火。
京王明云(23***97) 16:06:03
每个渠道一个接口。到了后端想统一就统一。
京王明云(23***97) 16:07:17
如果要谈设计，一个设计原则是，对外接口应该专用、精确。
EliteQ(87***60) 16:07:57
额， 那如何理解规约模式呢？
成殷小华(114***47) 16:08:12
还得看你的接口是不是只做加法，
京王明云(23***97) 16:08:37
PC、手机、微信，他们就是不同的渠道，为什么要把它们的接口统一起来呢？现在看统一起来没问题，但是将来很可能发生改变、扩展，那时候怎么办呢？
京王明云(23***97) 16:08:51
那时候就会相互受到制约。
成殷小华(114***47) 16:09:15
只要你的扩展不影响以前的接口，a肯定是比较好的选择。
EliteQ(87***60) 16:09:21
传统接口：
GetProductByID(int id)
GetProductByName(string name)
规约模式：
GetProduct(ISpecification spec)
京王明云(23***97) 16:09:29
例如手机接口因为某个原因，不得不再增加传递一个信息。于是，PC接口和微信接口就受影响。
EliteQ(87***60) 16:09:57
规约模式在设计模式上比传统接口要优秀很多啊
京王明云(23***97) 16:10:36
这不矛盾。
成殷小华(114***47) 16:11:09
a方案是各个接口不耦合。
京王明云(23***97) 16:11:12
GetProduct(ISpecification spec)
实际上是把分支路径包含在spec里了，你的spec会不同的，处理spec的代码也会不同的。
EliteQ(87***60) 16:11:24
b方案就是不停的加方法 a 方案就是与规约类似
京王明云(23***97) 16:11:49
你如果能够保证，这个规约将来保持比较稳定，那么可以。
EliteQ(87***60) 16:12:09
但是 a 方案可能被篡改啊
京王明云(23***97) 16:12:17
可是，本质的问题是，PC、微信、手机，他们就是不同的渠道，很可能将来会发生要扩展、要改变。
EliteQ(87***60) 16:12:23
毕竟不是真正的规约
京王明云(23***97) 16:14:53
一个设计理念是，把"变"和"不变"区分开。如果你的规约已经足够稳定，将来估计很少会变化了，那么可以用传递规约的形式。如果它还隐藏着、包含着可能的变化，那么要么你就继续把变化部分提炼出来，要么各自采用专一接口，为降低复杂度、将来进一步提炼变化留出空间。
上龚智勇(80**736) 16:17:22
你给的规约的方式是考虑到变化的。这个是比较好的
上龚智勇(80**736) 16:17:42
这样你的接口定义不会变了
上龚智勇(80**736) 16:18:02
不通的接入端，传入各自的规约
上龚智勇(80**736) 16:18:29
以后的扩展性就很强了。
成殷小华(114***47) 16:20:18
这种方案关键是要规范里面要预留变化。
上龚智勇(80**736) 16:20:48
变化都转移到规范里了
成殷小华(114***47) 16:21:14
就是规范里面要考虑到变化。
上龚智勇(80**736) 16:22:06
好处是可以增加新的规范
上龚智勇(80**736) 16:22:12
多种规范
上龚智勇(80**736) 16:22:35
接口本人不通，只是具体实现去动
上龚智勇(80**736) 16:22:47
接口本身不动
成殷小华(114***47) 16:22:48
主要考虑的是对客服端影响要降到最小。
上龚智勇(80**736) 16:23:23
这种模式，对客户端的影响最小
上龚智勇(80**736) 16:24:07
其实也算个偷懒模式
成殷小华(114***47) 16:24:20
双击查看原图
上龚智勇(80**736) 16:24:27
把所有的变化都扔给规范和实现了
京王明云(23***97) 16:25:59
可是，规约如果更新了，客户端不同样得更新版本么？
上龚智勇(80**736) 16:26:48
客户端使用规约1.0版本，新的可以是1.1啊
成殷小华(114***47) 16:26:57
可以不用更新的。
上龚智勇(80**736) 16:27:02
我后端1.0的调用1.0的实现
成殷小华(114***47) 16:27:14
新老版本兼容。
京王明云(23***97) 16:27:29
前端仍然用1.0，后端可更新到支持1.1，这个没有问题。
京王明云(23***97) 16:28:09
可是前端不更新，同样也就失去了更新的意义了——因为这个问题里的要求，就是要统计信息。1.0版本不能提供足够信息，是必然要更新的。
成殷小华(114***47) 16:28:21
规范做到兼容就行了。
京王明云(23***97) 16:28:49
影响到的是前端更新的复杂程度。
上龚智勇(80**736) 16:31:21
没看明白你说的意思
成殷小华(114***47) 16:32:20
规范做到兼容不会加大复杂度的。只更新变化部分即可。
小草(44***970) 16:35:04
内部系统 有PC/手机/微信 三种接入前端。 如果有一天对外开放了， 外部系统也有 PC/手机/微信 3种接入前端， 这个渠道的接口该怎么设计会比较好呢
小草(44***970) 16:35:19
如果对外开放，可以参考一些第三方的做法
小草(44***970) 16:35:26
例如微博，或者微信那种
小草(44***970) 16:35:38
第三方到你平台注册一个appId
小草(44***970) 16:35:48
这样你给他分配一个渠道号
小草(44***970) 16:35:57
一个appId对应这个渠道号，做不了假
涂文军(20***77) 17:13:16
appId可以假不？
小邪(80447993) 17:20:10
用同一个appId，分别登陆PC/手机/微信，应该会支持！
小邪(80447993) 17:20:20
所以...
EliteQ(87***60) 17:29:12
那个appID 是区分不同公司的，不能区分前端
EliteQ(87***60) 17:29:55
比如 来自于网易、来自于 微软，但并不能说清楚是 来自于网易PC网页 还是 网易APP
EliteQ(87***60) 17:30:46
所以我的要求 也简单， 对外，区分出不同的公司即可，对内，区分出具体的前端
潘加宇(3504847) 06:44:55
没说清楚这些"前端"是否"销售系统"的一部分？
假设"销售系统"指的是后面这部分，它应该只关注它自己的子领域的知识，该提供什么样的接口就提供什么样的接口，不需要考虑有哪几种"前端"，所以参数里有"渠道代号"或者"每个渠道一个操作"都是不需要的。
如何精细辨别各种前端并统计，防止假冒，这是另外一个子领域的知识，系统肯定需要另外一些类封装一些该子领域的知识，没有这些额外的知识，想靠变点花样解决问题，太难了吧。