依赖倒置原则

[liupan6888]

为什么说高层模块不应该依赖底层模块，而底层模块应该依赖于高层模块。是这么解释的：如果高层模块依赖于底层模块，那么底层模块的改动就会直接影响到高层模块，从而迫使它们依次做出改动。但是反过来，高层模块改动会不会影响到底层模块的改动呢？

[以专业开发人员为伍]

注意，这是指设计，而不是是指实现。 先设计接口，先用（貌似）可执行的代码书写需求，并且可以轻松地用语言描述和论证接口规约设计。 此时还没有实现，程序往往都不能编译通过。但是基本的架子有了。 好了，你现在认为当需要重构（重写）你的代码时，什么才是最稳定、应该坚持的呢？

[liupan6888]

我认为重构就是将代码清理干净，让其变得易易读。为了降低耦合，提高内聚，遵循依赖倒置原则是非常有用的。

[以专业开发人员为伍]

引用 2 楼 liupan6888 的回复:

我认为重构就是将代码清理干净，让其变得易易读。为了降低耦合，提高内聚，遵循依赖倒置原则是非常有用的。

这是不痛不痒的倾向于“平庸”的言论。 在一定情况下，重构可以随时随地展开，条件就是每一次重构时都要保证以前的合同全都遵守。那么好了，你还会在死抠什么底层几条代码、什么“程序员应该有洁癖”这方面为了重构而重构么？ 我们应该尽量从需求、市场、工程角度去理解重构，而不是从编程技术角度。

[以专业开发人员为伍]

如果你死抠一些代码，就好像“套中人”一样连个女亲戚的破衬衫都舍不得扔掉非要穿在自己（男人)身上，这种心情下你其实就不能重构了。 如果你把我到“这100个测试才是必须的、那500个简单描述才是必须的”，你这个时候需要“放下”那些已经写过的代码，你才能够重构。 因此“重构”其实不要用比较平庸的技术语言来解释它。越是了解重构，如果我们有做不完的令人兴奋的规划，我们往往不去进行平庸的学术化的所谓重构，而仅仅是把重构当作自然而然地、我们在规划中不断需要改变系统框架时的一种简单手段。

[以专业开发人员为伍]

我看我还是要跟你再重复一遍： 注意，你看到这个段落，这是指设计，而不是指实现。

[liupan6888]

听君一席话，胜读十年书。懂了很多。