优先考虑依赖注入来引用资源

本文是对《Effective Java》第2章5条的内容进行介绍和解读。这条建议先考虑使用依赖注入（Dependency Injection，DI）来用资源，而不是在类中直接创建资源的实。通过依赖注入，我们可以将资源的创建和管理责交给外部，提高代码的可维护性和活性。

为什么需要依赖注入？

在件开发过程中，我们经常需要引用外部，比如数据库连接、网络连接、线程池等。在用这些资源时，通常有两种方式：

1.接在类中创建资源实例。
2. 通过依赖入的方式将资源注入到类中。

直接在类创建资源实例的方式简单直接，但存在以下问题1. 维护性差：如果资源的创建和管理逻辑生变化，我们需要修改类的代码。这可能会导代码的脆弱性，增加维护的成本。
2 灵活性差：如果我们希望在不同的场景使用不同的资源实现，比如在测试时使用模资源，在生产环境使用真实资源，那么直接类中创建资源实例的方式将无法满足需求因此，为了提高代码的可维护性和灵性，我们应该优先考虑使用依赖注入来用资源。

什么是依赖注入？

依赖入是一种设计模式，通过这种模式可以将对象所依赖的另一个对象的引用注入到对象，从而解耦对象之间的关系。依赖注有多种实现方式，比如构造器注入、注入、属性注入等。

以构造器注入为，我们可以通过构造器来接收依赖对象的实：

public class ResourceConsumer {
    private final Resource resource;

 public ResourceConsumer(Resource resource) {
        this.resource = resource;
    }

 public void doSomething() {
        // 使用resource对象进行操作
   }

在上述示例代码中，ResourceConsumer通过构造器接收一个Resource对象的实例，并其保存到成员变量resource中。这样，ResourceConsumer类就可以在doSomething()`方法中使用``对象进行操作。

依赖注入的优势

依赖注入的方式引用资源具有以下优势：

. 解耦性：依赖注入将资源的创建和管理辑抽象到外部，使得类只关注自己正的业务逻辑，降低了类之间的耦度。
2. 可维护性：如果资源的创建和管理辑发生变化，我们只需要修改外部的依赖入逻辑，而不需要修改类的代码，减少了的脆弱性。
3. 灵活性：通过依赖注，我们可以在不同的场景下使用不同的资源现。例如，在测试时可以使用模拟资源，在生产环中使用真实资源。

依赖注入的示例下面以一个简单的示例来说明如何使用依入来引用资源。

public class EmailSender {
 private final EmailService emailService;

    public EmailSender(EmailService email) {
        this.emailService = emailService;
    }

    public voidEmail(String recipient, String message) {
        emailService.sendEmail(recipient message);
    }
}

在上述示例代码中，EmailSender类通过构造器接收一个EmailService的实例，并将其保存到成员变量emailService中。在发送邮件时，EmailSender类使用Service对象调用sendEmail()方法。

通过依赖注的方式，我们可以在不同的场景下使用不同EmailService实现。例如，在测试中可以使用一个模的EmailService实现：

public class MockEmail implements EmailService {
    public void sendEmail(String recipient, String message)        // 模拟发送邮件的逻辑
        // ...
   }

在生产环境中，我们可以使用一个真的EmailService实现：

public class RealEmail implements EmailService {
    public void sendEmail(String recipient, String message)        // 真实发送邮件的逻辑
        // ...
   }

通过将不同的实现注入到Email类中，我们可以在不同的环境中使用不的资源实现，提高了代码的灵活性。

结论

在引用资源的时候，优先考虑使用赖注入的方式。依赖注入可以提高代码的维护性和灵活性，降低类之间的耦度。通过将资源的创建和管理逻辑抽象到外，我们可以在不同的场景下使用不同的资源现。