我不想在以后的新功能里再调用这个玩意儿了,哈哈
不改变已有调用者代码的办法,就是2楼dilemma说的办法,
针对老的调用者表现出接口语义不变,但改成返回一个带operator const std::string &()操作符重载的struct。新的调用者可以用这个struct里导出的新接口。
AI给的也是这个办法。
老调用者拿到混合的std::string后,
1、如果带###Error###,就认为失败,并记录失败log到文件。
2、如果是Content not modified,就需要从自己搞的缓存里拿出上次成功的串来使用。
3、否则就是成功,缓存到自己的某个地方,并使用。
其中,2不能简单和1一样以失败了之,因为有两个url接口的返回值要联合起来使用的情况,
比如:
url1返回成功(有新的策略或者配置数据),而url2返回Content not modified(策略或者配置数据没变),
然后url1和url2的响应数据要做一个关联处理(实际就是把服务端的关联计算的开销给移到客户端了)。
这种情况下url2不能把Content not modified当作失败来处理,否则会导致url1的更新也等于是失败了。
另外,我打算把成功的结果统一在HttpPost()的内部进行缓存,而无需每个调用者自己缓存。
只缓存带etag的请求。
这个缓存在多线程下是存在race从而导致miss的,比如:
线程A先请求url1,拿到成功值,
而线程B以同样的参数后请求url1,拿到的是Content not modified,但此时线程A并不一定就把成功值放入缓存了,就产生cache miss。这种先就当作失败处理好了。
如果我放弃对现有这个HttpPost()的重构,调用这个老接口的代码也不动,
而另起炉灶搞一个HttpPost2(), 只给新功能用,也会因为上面说的这个统一缓存,而需要在老接口HttpPost()里对缓存进行CRUD。
【 在 ziqin 的大作中提到: 】
: 重构的目的是什么?让代码可读性变强还是增加性能?如果是纯业务逻辑,没什么重构的必要
--
FROM 111.199.147.*