为啥说用接口，切换实现类就不用改代码？

[abc`1]

举个例子：
service现在注入一个”myDao“：

public class MyServiceImpl {
   
   @Resource("myDao")
    private MyDao myDao;

}

}

然后现在切换到新的”myDao2“，不就是改了代码吗？

public class MyServiceImpl {
   
   @Resource("myDao2")
    private MyDao myDao;

}

}

[maradona1984]

这种算配置型的代码,改动影响很小,当然你也可以做成不改代码的,纯粹配置型,也可以做到,只是没啥必要

[abc`1]

引用 1 楼 maradona1984 的回复:

这种算配置型的代码,改动影响很小,当然你也可以做成不改代码的,纯粹配置型,也可以做到,只是没啥必要

那注入接口就可有可以无了，直接注入实现类也一样，切换新实现类也只是改一行类名

[得一以生]

第一种方式：接口A，定义方法do()，实现类B,C,D，都实现方法do()，调用方永远只需要引入private A a，通过xml或者注解配置实现类B,C,D其中之一即可 第二种方式：X,Y,Z，都有各自的方法doX()，doY()，doZ()，这个月客户希望用X的方法处理业务，下个月希望用Y的方法处理业务，再下个月用Z的方法处理业务，就需要不停的改代码，重新打包发布，这样每个月都要停机，部署，重启，如果业务处理变动频繁，对客户来说是灾难性的，所以这就是接口存在的意义，对外统一方法，对内动态决定实现方，这样的好处是1、对外暴露的api统一，包括方法名，入参2、动态配置业务实现。3、B，C，D的开发者专注自己的业务实现。

[maradona1984]

引用 2 楼 Wuicy 的回复:

[quote=引用 1 楼 maradona1984 的回复:]这种算配置型的代码,改动影响很小,当然你也可以做成不改代码的,纯粹配置型,也可以做到,只是没啥必要

那注入接口就可有可以无了，直接注入实现类也一样，切换新实现类也只是改一行类名[/quote] 注入类?接口能保证方法一致,但类就不能了啊,语法这东西,都是从编译期去限制,类从语言层面就没法去限制了

[abc`1]

引用 4 楼 maradona1984 的回复:

[quote=引用 2 楼 Wuicy 的回复:][quote=引用 1 楼 maradona1984 的回复:]这种算配置型的代码,改动影响很小,当然你也可以做成不改代码的,纯粹配置型,也可以做到,只是没啥必要

那注入接口就可有可以无了，直接注入实现类也一样，切换新实现类也只是改一行类名[/quote] 注入类?接口能保证方法一致,但类就不能了啊,语法这东西,都是从编译期去限制,类从语言层面就没法去限制了[/quote] 我的意思是，两个实现类都实现一个接口，但是注入的时候直接注入实现类

[maradona1984]

引用 5 楼 Wuicy 的回复:

[quote=引用 4 楼 maradona1984 的回复:][quote=引用 2 楼 Wuicy 的回复:][quote=引用 1 楼 maradona1984 的回复:]这种算配置型的代码,改动影响很小,当然你也可以做成不改代码的,纯粹配置型,也可以做到,只是没啥必要

那注入接口就可有可以无了，直接注入实现类也一样，切换新实现类也只是改一行类名[/quote] 注入类?接口能保证方法一致,但类就不能了啊,语法这东西,都是从编译期去限制,类从语言层面就没法去限制了[/quote] 我的意思是，两个实现类都实现一个接口，但是注入的时候直接注入实现类[/quote] 理论上是可以的,但何必呢,你修改注入的bean name就相当于选择不同bean了,何必再去修改类型呢?做为一个程序员,少修改一行就少一分出bug的概率. 还有你既然定义了接口,那成员变量为何要选择定义一个实现类,这点就是相当奇怪的,代码并不是只管运行结果,还要让人能看懂这段代码的意图,可以减少其他人的工作量,别人一看到接口定义在这里,那就透露了作者的意图,这里是可扩展的,如果你写个实现类放那,别人就算看到了这个类的接口,那也需要更多沟通/测试来保证代码的意图,而不像接口那样一目了然.