依赖倒置原则

高层模块不应该依赖低层模块，两者都应该依赖其抽象（模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的）
抽象不应该依赖细节（接口或抽象类不依赖于实现类），细节应该依赖抽象（实现类依赖接口或抽象类）

优势

减少类间的耦合性，提高系统的稳定性
降低并行开发引起的风险
提高代码的可读性和可维护性

例子

场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。代码如下：


fun main(args: Array<String>) {
    Client().onMotherNarrate()
}

class Book {
    //故事内容
    fun getContent(): String = "很久很久以前有一个阿拉伯的故事……"
}

class Mother {
    /**
     * 讲故事
     */
    fun narrate(book: Book) {
        println("妈妈开始讲故事")
        println(book.getContent())
    }
}

class Client {
    fun onMotherNarrate() {
        println("孩子要听故事")
        val mother = Mother()
        mother.narrate(Book())
    }
}

假如有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码如下：


class Newspaper{
    //报纸内容
    fun getContent(): String ="商务部相关负责人在接受本台记者采访时表示……"
}

只是将书换成报纸，居然必须要修改Mother才能读。假如以后需求换成杂志呢？换成网页呢？还要不断地修改Mother，这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了，必须降低他们之间的耦合度才行。

我们引入一个抽象的接口IReader。读物，只要是带字的都属于读物：

/**
 * 读物接口
 */
interface IReader {
    /**
     * 读物内容
     */
    fun getContent(): String
}

Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：

class Newspaper:IReader {
    //报纸内容
    override fun getContent(): String = "商务部相关负责人在接受本台记者采访时表示，目前，……"
}

class Book:IReader {
    //故事内容
    override fun getContent(): String = "很久很久以前有一个阿拉伯的故事……"
}

class Mother {
    /**
     * 讲故事
     */
    fun narrate(reader:IReader) {
        println("妈妈开始讲${
            if(reader is Book){
                "故事"
            }else{
                "报纸"
            }
        }")
        println(reader.getContent())
    }
}

class Client {
    fun onMotherNarrate() {
        val mother = Mother()
        println("孩子要听故事")
        mother.narrate(Book())
        println("孩子要听报纸")
        mother.narrate(Newspaper())
    }
}

这样修改后，无论以后怎样扩展Client类，都不需要再修改Mother类了。这只是一个简单的例子，实际情况中，代表高层模块的Mother类将负责完成主要的业务逻辑，一旦需要对它进行修改，引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。

开发注意

低层模块尽量都要有抽象类或接口，或者两者都有。
变量的声明类型尽量是抽象类或接口。
使用继承时遵循里氏替换原则。