依赖倒置像金鱼，好看但难养
依赖倒置像金鱼，好看但难养依赖导致是解耦的核心之一，但它就像金鱼一样，看着好看，缺很难伺候。 ================ 依赖倒置 - 面向接口编程。（是不是一下变得高大上了？） 依赖倒置的核心：模块之间的依赖通过抽象（抽象类、接口）产生 上一章我们聊了继承，这章聊实现。 我理解的面向接口编程字面意思，是通过接口产生依赖关系。实现类不直接发生交互。那么接口是什么呢？ 接口是规则的集合 接口设定了一系列的规则，面向接口编程就是 面向规则编程。 再简单说下什么是规则。规则就是类A你要给我提供getX方法和setX方法，至于你怎么实现，我不管。规则我给你定好了，你实现吧。 那么这样做的好处是什么呢？ 就好比地球上大国的高层领导，领导和领导们之间玩的都是规则，他们在上层发号命令。下面的小兵兵们实现就好了，只有小兵兵们怎么做，他们才不管呢，这是小兵兵们需要考虑的问题。每一年的情况都不同，所以每一年同一个命令的实现方式也不同，作为小兵兵的要为上层考虑，不能让他们“劳心尽力”，考虑这些小问题。所以上次并不知道每一年他命令的实现都不同。这就保持了稳定！ 看！面向接口编程的目的是实现解耦，解耦的目的是保持修改的最小化，保持稳定。 面向接口编程是不是太棒了？ 说的永远比唱的好听。这回，我们从坏处开始讲： 面向接口编程的贯彻者：MVP架构MVP应该是现有架构里，面向接口编程最彻底的了。M-V-P三层为了实现最大程度解耦，全部采用接口实现依赖。设想是好的，实际也是有好处的。但真正的实践者依然很少，因为它优点是那么诱人，但缺点是却是那么致命！！ 人不是万能的，不可能提前想好所有的规则。需求也是多变的，不可能保持稳定。（虽然MVP就是应对需求多变的） 面对规则设定的不稳定，直接现象就是接口大规模变动。而更多时候，很可能是三层接口跟着变动。三层接口跟着变动的后果就是，三层的实现类需要跟着修改。你能想象这有多么痛苦吗？ 当然必须要承认的是，一旦架构稳定下来，步入中后期维护，MVP带来的优点将会逐渐体现出来。就好像LOL里的后期英雄一样。 真实场景中的依赖倒置其实不说MVP架构，真正的项目中，除了独立库以外，符合依赖倒置原则的地方也并不多。（后端架构不太清楚，但客户端至少是这样）。 毕竟接口的设计成本也是很大的，而业务需求的变动往往也有没有想象中那么大，直接修改实现类的成本有时反而是很小的。 所以实际项目中并没有必要一定遵循依赖倒置原则，考虑一下这真的是必须的吗？ 但是在边写依赖库时，对门面的设计，还是要面向接口，对内部信息做隐蔽。 依赖倒置的好处说了半天，依赖导致好像变成一个花瓶一样的东西。但他还是有很大好处的，只要我们注意使用就行。
结论从我个人的角度，是拒绝依赖倒置的大面积普及的。但我依然很喜欢依赖倒置，在一些规则稳定的场景，依赖倒置不失为一把解耦利器！！ （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |