如果在代码中使用具体的依赖为啥会难以维护，请举例子具体解释原因

在代码中直接使用具体的依赖会导致难以维护的主要原因是耦合性增加。耦合度高意味着代码之间的依赖关系紧密，一处的修改可能会导致其他地方的改动，从而增加了代码维护的难度。以下是一个具体的示例来解释原因：

假设我们有一个订单管理系统，其中包含一个OrderService类和一个EmailService类。OrderService负责处理订单相关的业务逻辑，而EmailService负责发送邮件通知。在没有使用依赖注入的情况下，OrderService直接实例化了EmailService对象来发送邮件。

public class OrderService {
    private EmailService emailService = new EmailService(); // 直接实例化依赖对象

    //...
}

现在假设我们需要修改EmailService的实现，比如更换为新的邮件发送服务商。由于OrderService直接依赖于EmailService的具体实现，我们不得不修改OrderService的代码来适应这个改变。

public class OrderService {
    private EmailService emailService = new NewEmailService(); // 修改为新的邮件服务商

    //...
}

这样的修改可能会牵涉到多个类和模块，增加了代码维护的复杂性。如果系统中有多个类直接依赖于EmailService，那么修改EmailService的实现将会对整个系统造成连锁反应，需要大规模的代码修改和测试。

另外，直接实例化依赖对象还会导致代码的可测试性降低。在进行单元测试时，由于无法轻松地替换依赖对象，我们不得不在测试中创建并管理额外的依赖对象，增加了测试的复杂性和成本。

综上所述，直接使用具体的依赖会增加代码的耦合性，使得代码难以维护。通过使用依赖注入，我们可以将依赖对象的创建和管理交给外部容器，从而降低耦合度，并提高代码的可维护性和可测试性。