依赖注入简单地说，就是类应该依赖于抽象，例如数据源的抽象，而不是具体的实现。这意味着类将依赖于接口而不是真正的类。

这有几个好处：
1，在不更改客户端代码的情况下，很容易将一个实现转换为另一个实现。
2，由于接口通常只覆盖类的总API的一小部分，因此可以精确地确定哪个类可以访问哪些方法和功能。

例如，如果有一个数据源类，可以有一个读接口和一个写接口，也可以有两个接口的组合。然后，每个客户端可以根据需要拥有其中的任意一个接口，这是最小特权原则的一个例子。

它看起来像这样：

该模式的总结是：应该依赖于接口，而不是具体的实现，这使得交换相同功能的不同实现变得更加容易。

下面在Rust中实现这个模式：
在这个例子中，将建立一个虚构的汽车工厂，它只需要轮子：大轮子和小轮子。由于生产这种轮子的机器具有相同的界面或特性，我们可以使用它：

trait WheelProducer {
    fn produce_wheel(&self) -> String;
}

然后，定义一个CarFactory结构体，它拥有一个WheelProducer的实例：

struct CarFactory {
    wheel_producer: Box<dyn WheelProducer>
}

impl CarFactory {
    fn change_wheel_producer(&mut self, wheel_producer: Box<dyn WheelProducer>) {
        self.wheel_producer = wheel_producer;
    }
}

因为WheelProducer是一个trait对象，所以我们必须使用dyn关键字。此外，由于事先不知道生产者的大小，我们必须把它放在一个Box里。

现在来看看我们的第一个WheelProducer：

struct SmallWheelProducer;
 // 堆代码 duidaima.com
impl WheelProducer for SmallWheelProducer {
    fn produce_wheel(&self) -> String {
        "Small wheel".to_string()
    }
}

SmallWheelProducer实现了WheelProducer接口。接下来我们对BigWheelProducer做同样的事情：

struct BigWheelProducer;

impl WheelProducer for BigWheelProducer {
    fn produce_wheel(&self) -> String {
        "Big wheel".to_string()
    }
}

现在可以测试我们的设置：

fn main() {
    let small_wheel_producer = SmallWheelProducer;
    let mut factory = CarFactory {
        wheel_producer: Box::new(small_wheel_producer)
    };

    // 生产大轮子的代码与生产小轮子的代码一致
    let wheel = factory.wheel_producer.produce_wheel();
    println!("Wheel produced: {}",wheel);

    let big_wheel_producer = Box::new(BigWheelProducer);
    factory.change_wheel_producer(big_wheel_producer);

    // 生产大轮子的代码与生产小轮子的代码一致
    let wheel = factory.wheel_producer.produce_wheel();
    println!("Wheel produced: {}",wheel);
}

在我们的简单示例中，手动执行此操作非常容易，然而，在更高级的示例中，它可能变得容易出错且麻烦。下面的 lib 库为我们实现了依赖注入和控制反转。


实现依赖注入的crate：
Inject：实现了用于依赖性解析的宏，体现了控制反转(IoC)原则。
Syrette：方便的Rust依赖注入和控制反转框架。

实现这种模式并不十分困难，需要记住的主要事情是面向接口编程而不是具体的实现。