过度设计，讨厌的很，美其名曰标准化

直接new不好吗

java本来就是以又臭又长著称

一般写这类代码都用代码生成器，其次程序设计有个原则是依赖抽象

95%业务类的service层可以预见的是基本一个interface只有一个implements实现类。除非搞微服务进行调用层级解耦，这些interface很多都是过度设计。业内的常见心态是，大家都这么搞错不了，我也这么搞，不明所以

小项目随便，大项目有用，不这样的话，以后扩展有你好受

python转java肯定会觉得用不惯的，当然和语言其实也没关系，都是框架和设计上的区别

我也是极其不习惯，各种模式绕来绕去。还是C/C++ 极其简洁明了。当然模式有模式的好处，C/C++就不适合写大规模的业务处理项目。

N年前一个C转JAVA的也对我吐槽过这，我说如果你不需要用到JAVA多态性，不需要代理和反射，只是一个简单的util，那就随便用。

没有interface，怎么做rpc，怎么做微服务

这就看出来你们公司是做大工程还是小工程的了。。。

如此看来，还是得学java。

只能说你还不了解java，思维转变不过来，字里行间都是抗拒

留口子这种东西就是你不留，后面就一定会难受，虽然大概率留了后面也不用。。。

等你遇到一个方法里面2000多行代码的, 你就明白, 为啥要用java了

这个是不需要的，早些年要这个玩意儿是因为Java只支持接口代理…

至于微服务，你用HTTP通信的话，也不需要接口；好像就dubbo强依赖这玩意儿。

接口嘛，顾名思义，和现实很像。就像电脑主板的接口，那么多，但是很多你都用不上。但是真要用的时候，没接口又不行，所以还是得有。

你还是回去写你的小作坊代码吧，整个java推荐的都是面向接口编程

诞生于1995年的语言，你就别对语法苛求太多了。

java就是擅长把简单的东西弄复杂，尤其是所谓的设计模式。

这个，我想说一个事实，spring本身并没有要求一定要interface之后再impl他。
也就是说，你只需要借助spring的ioc就好，直接autowired一个类（无接口）也是没有任何问题的。

根据项目大小，人员分工的不同，采用不同的实现方式即可，这个和spring有什么关系？
spring只是个容器，借助它用来规范整个团队，很方便。