如何对业务代码中进行抽象和提取公有逻辑呢？

[zstone123]

之前写的代码可能比较随意，没有考虑过这个问题。现在遇到的问题是两个接口代码相似度可能超过 80%。
1.对相同的代码封装为函数，不同的代码用接口去实现。（只是这么一个想法，但具体没啥实现思路
2.将两个接口合为一个接口。这样的问题是可能会多了许多 if/else 。
真心向各位请教一下，有什么比较好的做法。

[connection]

1. 不建议 "重复" => "抽象"，错误的抽象比多余的重复更可怕 https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction 。
2. 重构是一个持续的过程。
3. 可以找本《 clean code 》找找感觉。

[zstone123]

@connection 多谢你的回答。
1.如果不去抽象，那么是否可能对部分重复的代码进行封装是更好的选择。
2.那又该如何面对 Don't Repeat Yourself 原则呢。

[hackyuan]

即使是错误的抽象也要抽象，需要刻意训练，多练多使用，隔半个再看看之前抽象的是否恰当。
其余的就是多看开源代码，学习他们的技巧。

[revlis7]

我的个人感受是，合理的抽象解耦 > 冗余代码 > 粗暴的代码封装，但实际情况是没有那么多时间给你做抽象解耦，尤其是频繁变动的业务逻辑，所以更多的时候选择冗余代码。除非你有完备的测试，否则你永远不知道你的一次改动会造成多大的影响。

[3dwelcome]

别听一楼的，编程路想要走的久。就要不断提取共同代码，不积累自己的类库，否则又怎么会有技术成长？

所谓“错误的抽象”，无非就是模块之间的耦合性过强。仔细思考，把模块一个个抽丝剥茧即可。

还有那句“duplication is far cheaper”，我最恨的就是写一堆重复代码了，时间一久，你完全无法分辨哪些代码能删，哪些不能。

[dozeboy]

尝试把重复代码提取到足够小的单元，类或者方法中。根据「单一职责」「组合优于继承」等设计原则来优化代码，慢慢就有进步了。

[ayase252]

可以看看重构第二版，了解一下代码中的坏味道。
小步重构去掉坏味道，留下来的就是架构比较好的代码了

[xuanbg]

抽象意味着剥离特性，需要对业务有非常深刻的理解，认知的深度已经触及本质而非停留在表面。譬如关系数据库，就是对一般数据的结构及存储需求的抽象。

上面几楼说的都不是抽象而仅仅是封装。对于我们的业务代码而言，封装的重要性其实远高于抽象。

[chenqh]

实在不行用多继承,每个继承只做一类事情

[felixin]

业务逻辑用 uncle bob 的 clean code 是正解。

抽象和重复是一体两面的，并没有哪个更好的说法，一切都得看架构设计的权衡和利弊分析。

dry 原则只是初级阶段，不用死守。

[e583409]

重复代码 还有一个坏处就是维护与测试成本高 改了一个地方 可能还要修改另外一个地方 对代码有追求本身就是一种自我提升的手段和途径
不然 CRUD 怎么提升

[yidinghe]

想要建立抽象的思维方式，最好就是多读热门框架的代码，看懂那些套路。

[312ybj]

还是实践出真知， 你们系统里有优秀的代码案例吗，如果有的话可以参考下。如果没有，我建议从模板方法开始入手，自己写一个接口，写一个抽象类， 公共的业务放到上层，个性化的需求放在实现类里。 抽象是个过程，可以一边写代码，一边画流程图 uml 图，熟能生巧。

[a719031256]

首先你得确定你做的业务需求变化大不大频繁不频繁

如果不大不频繁的话可以做合并

反之则不建议做合并，更应该做拆分

[fpure]

只能说很多人误用了 DRY 原则（ DRY 原则和开闭原则是我见过最多人误用的编程原则）。实践 DRY 原则应该明白什么应该抽象什么应该冗余，我认为抽象的是同一问题的解决方案，冗余的是代码。所以并不是两段代码看起来相似就应该抽象，而是要考虑这两段代码是否是在解决本质上同一问题。

[ebingtel]

写测试，是重构的前提

[skys215]

了解一下领域驱动设计？

[JJsty1e]

@e583409 虽然我不推崇写重复代码，但是你这个例子不恰当，因为有时候你也会发现按需要改了一个地方，引用这份代码的另一个地方却出了问题所以根源在于，在代码变更过之后，测试能否覆盖到

[qq648988741]

补充个点吧，如果没想好怎么做，先尝试写写文档，整理清楚思路，再来看看怎么做

[yyysuo]

把足够独立的逻辑，小范围的封闭成积木，然后用积木搭建大厦。不要想着造大的积木。