依赖反转原则

依赖反转原则的核心思想是：内层模块不应该依赖外层模块,它们都应该依赖于抽象。

尽管我们会花很多时间去考虑哪些模块分别放到内层和外层，尽量保证它们处于单向依赖关系。但在实际开发中，总还是有不少内层模块需要依赖外层模块的场景。

比如在 Localstorge 和 Indexdb 的例子里，User 模块作为内层的核心业务逻辑，却依赖了外层易变的 Localstorge 和 Indexdb 模块，导致 User 模块变得不稳定。

import ‘localstorge’ from 'localstorge';

class User{
    save(){
        localstorge.save('xxx');
    }
}

const user = new User();
user.save();

缺图

为了解决 User 模块的稳定性问题，我们引入了 DB 抽象接口，这个接口是相对稳定的，User 模块改为去依赖 DB 抽象接口，从而让 User 变成一个稳定的模块。

Interface DB{
   save(): void;
}

然后让核心业务模块 User 仅仅依赖这个接口：

import DB from 'DB';

class User{
    constructor(
        private db: DB
   ){

    }
    save(){
        this.db.save('xxx');
    }
}

接着让 Localstorge 和 Indexdb 分别实现 DB 接口：

class Localstorge implements DB{
    save(str:string){
        ...//do something
    }
}

依赖关系变成：缺图

User -> DB <- Localstorge

在图 1 和图 2 看来，User 模块不再显式的依赖 Localstorge，而是依赖稳定的 DB 接口，DB 到底是什么，会在程序后期，由其他外层模块将 Localstorge 或者 Indexdb 注入进来，这里的依赖关系看起来被反转了，这种方式被称为“依赖反转”。