背景
最近项目进入推广期，新需求开始变少，闲来无事便想着重构一下之前的代码，之前为了快速迭代上线，没有仔细考虑代码的结构，导致代码结构混乱不堪，类与类之间关系复杂，代码的可读性很差，也不方便后续的扩展和维护。可能有些同学不明白，为啥写好的代码要进行重构。这里解释一下，代码其实是写给人看的，而不是给机器看的，所以保持代码的整洁和结构的清晰是非常有必要的。
重构
这是我们今天要进行重构的模块，主要是其中的EBaiService,MeiTuanService,LyhService,YfwService,OtoOrderService,OtoService这几个类，OtoOrderService是处理oto订单的类，otoService是来处理各种oto之间相同的部分，像订单入库流程，商品信息同步流程等，看命名就知道，主要就是针对oto业务的。现在主要的问题是，类和类之间的关系太过复杂，因为oto服务实现的功能都是类似的，所以我这里只拿美团和饿了么做例子，像下面这张图一样：
这样的依赖是很不好的，因为我们希望我们的类也是单一职责，美团的服务就只做美团的工作，otoservice来做公共的功能，而otoOrderService则是做一个分发，将接口接收到的信息，按照美团和饿了么这样分类给每个单独的服务处理，这样既简洁又清晰，像下面这张图一样：
这样看来的话，我们只需要吧otoOrderService和OtoService之间的关系切断就可以了。接下来就到我们今天的问题了，如图，现在有两个方法，getOtoModel依赖于updateOtoOrderList，重构前他们都在OtoOrderService里面，没有问题。
现在我要把这两个方法移到公共模块，也就是OtoService里面
本来我的重构到这就结束了，但是这里又出现了一个问题，我们从图中可以看出otoService和EBaiService，MeiTuanService出现了循环依赖。
解决方案
这时我想到了一个办法，那就是把这两个方法拆开，分别在EBaiService和MeiTuanService里面实现一份，但是这又会产生一个问题，就是我的代码冗余了，而且在oto的种类越来越多的时候，这部分的代码就是冗余的越来越多，很大程度上增加了我的后续维护成本。
正在思考的时候我想到了我们设计代码时候的一个原则，依赖倒置原则。
依赖倒置原则（Dependence Inversion Principle,DIP）是指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。
通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的 可读性和可维护性，并能够降低修改程序所造成的风险。
这里我们把OtoService当成高层代码，而EBaiService和MeiTuanService就是底层模块，那么我们就可以把EBaiService和MeiTuanService抽象出来变成IOtoService，并把IOtoService作为updateOtoOrderList的参数这样就解决了之前出现的循环依赖的问题也完成了我们的重构。
