用工具类or采用spring bean的接口注入方式

和领导的一次对话，记录一下
背景:项目中引入configuration自己封装的框架，很多静态方法需要改成非静态方法，或者通过增加很多参数来实现，感觉很鸡肋，这些数据通过spring注入，越写越不灵活。

领导：
为啥那些逻辑要用静态调用？
啥场景下的逻辑适合用静态调用？
为啥逻辑不用接口或者spring bean?
我换一个问题，你觉得啥样的类，适合用静态类和静态方法？

小白:
修饰成员变量(静态变量)静态成员属于类。被这个类的所有实例所共享
在内存中只有一个拷贝，节省内存，通过类名直接访问，十分方便。

修饰成员方法(静态方法)
无需每次都要new实例化，因为编译后就已经分配好内存，通过类名.方法来调用

修饰代码块(静态代码块)
当jvm加载类时，静态代码块的内容会先于其他代码块执行，且只会被执行一次。

领导：
spring bean 也默认是单例，除了第二点，你说的上面的优点也都有

我再问一个问题
你能举个例子，在面向对象的特征里，哪个是用静态类来实现的？在设计模式里，哪些模式是用静态类的？

小白：
单例，工厂，建造者

领导：
那我们代码里的那些静态调用，是用了这些模式吗？
单例的目标是对象全生命周期内唯一，spring bean本身也是单例
工厂类也不是必须是单例，工厂本身也可以是接口

小白：
大部分都是作为工具类在使用，没有涉及设计模式，主要是调用起来方便

领导：
对，我们还是回到问题的本源，工具类的约束，啥样的类才适合工具类？

小白：
安全，通用，提升性能，一次初始化，处处使用

领导：
上面的回答，只有通用我是认可的
其他三条并不成立
欢迎你继续反驳我

小白：太难了

领导：
方便这个理由，我不接受，
方便不代表正确合理
一个类是不是好代码，更应该减少耦合，降低重复等角度来衡量
静态调用最大的问题就是依赖实现，增加耦合

第