简介：
ð¶Love会受伤，但有时Love会吸烟您的代码库！ ð¶让我们谈谈为什么心爱的@autowed spring启动中的注释可能不是您依赖注入需求的最佳匹配。在本文中，我们将探讨使用@Autowied的弊端，讨论其对您的代码库的影响，并提出替代策略，以保持您的代码库清洁和健康。让我们潜入！ ð

1. ð@autowired怎么了？
   第一件事首先！ @Autow的注释最初可能看起来像是在天堂做的一场比赛，在您的春季靴子项目中毫不费力地注入。但是，过度依靠@Autowed会导致几个问题，从而将其变成编码气味。让我们分解它们：

2. - 紧密耦合警报！
   @Autowired的一个主要缺点是，它紧密地耦合了您的组件，创建了难以追踪和维护的依赖网络（不是其他形式的依赖注入不，它们只是易于识别）。随着代码库的增长，确定依赖关系的确切位置成为一项艰巨的任务。以以下示例：
   

@Component
public class ServiceA {
    @Autowired
    private ServiceB serviceB;

    // ...
}

在这里，Servicea直接取决于ServiceB，严重限制了代码的灵活性。 ServiceB的更改或添加替代实现可能会导致整个代码库中的级联更改。 ð±

1. ð隐藏的依赖关系 当利用@Autowired时，您可能会遇到依赖关系不清楚或隐藏的实例。这会产生不确定性的面纱，使开发人员更难理解与之互动的组件的内部工作和要求。考虑此示例：

@Component
public class ShoppingCartService {
    @Autowired
    private PaymentService paymentService;

    // ...
}

没有明确声明对构造函数或方法参数中的付款服务的要求，在您的代码中加速的新开发人员可能难以掌握shoppingcartservice的基本依赖性或完全错过它们。 ð

1. ð测试成为一场噩梦 广泛使用@autowed时，编写测试用例变得越来越复杂。为了有效地测试单个组件，您通常最终会拖动多个依赖项并配置精美的设置。这使得测试案例脆弱且难以维护。看看这个示例：

@SpringBootTest
class CustomerServiceTest {
    @Autowired
    private CustomerService customerService;

    @Autowired
    private OrderService orderService;

    @Autowired
    private PaymentService paymentService;

    // ...
}

在这种情况下，由于成功执行测试所需的级联依赖关系，测试客户服务变得乏味。 ð

ð清洁健康的替代方案：

构造函数注入

那么，我们如何克服这些挑战？ ð造型器注入救援！构造函数注入可促进依赖关系的明确声明，并允许更清晰的代码理解。让我们看看重组的例子：

@Component
public class ServiceA {
    private final ServiceB serviceB;

    public ServiceA(ServiceB serviceB) {
        this.serviceB = serviceB;
    }
    // ...
}

@Component
public class ShoppingCartService {
    private final PaymentService paymentService;

    public ShoppingCartService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
    // ...
}

通过使用构造函数注入，我们消除了惊喜并明确使依赖项明确，从而导致更清洁，更可维护的代码。 ð§万

结论：
在本文中，我们提到了一些过度依赖Spring Boot的@Autowed注释来依赖注入的缺点。我们探索了它所带来的挑战，例如紧密的耦合，隐藏的依赖性和测试复杂性。幸运的是，我们提出了一个优雅的解决方案 - 构造仪注入。拥抱构造函数注入，您将培养干净，可理解且无麻烦的代码库进行测试！ ð

记住，虽然可以在您的编码冒险中与@Autowed一起逃跑，但在蜜月阶段结束后分手以确保与代码库建立持久，健康的关系是至关重要的。愉快的编码！ ð»ð