请教下，项目中静态方法过多有什么缺点？

[NULL2020]

最近被朋友拉拢一起搞个小项目，我算是目前最后入伙的。

前几天提了个建议，把 redis 的工具类改成静态方法的形式（现在是以 spring bean 的形式交给容器管理），方便调用。结果另一位后端说不要，静态方法太多不好，问他为什么，说叫自己去看 JVM （黑人问号脸）。

我思考几天，也 google 了下，也没见着有特别有说服力的说法，自己勉强想到了一个点，那可能就是会导致 JVM 静态方法区容量过大，最终引起 OOM ?

但是，说实话，一个小项目，也就那点代码量，连一个工具类这点内存都要省了吗？

[FreeEx]

问题不在于静态方法，而在于上了 spring 的船为什么不用 RedisTemplate ？

[NULL2020]

@FreeEx 仔细审题，用的就是 RedisTemplate，我的工具类只是把它再进行一次简单的封装，使用静态方法的方式调用。

@encro
@no1xsyzy
两位大佬洋洋洒洒，我一句没看懂。。/doge

[NULL2020]

@CODEWEA 你的回复我也没看出来有什么价值

[Marszm]

幸好,我们这边就我懂 redis..我想怎么用怎么用..

[namelosw]

把 redis 的工具类改成静态方法的形式（现在是以 spring bean 的形式交给容器管理），方便调用

> 我怀疑你们很少写测试

[namelosw]

@no1xsyzy 其实 Haskell 也用依赖注入，只不过是走 Reader Monad 或者 Tagless Final 的形式。

他这个问题本质上就是回答系统会有几个 Redis （比如有假的 Redis 用来测试，或者用来做六边形架构，下面可能会替换多套实现），如果大于 1，就走依赖注入，如果等于 1 就无所谓。

[chocotan]

封不封装跟静态方法一点关系都没有

[est]

redis 还是建议不要搞成静态方法。因为这玩意一般还要挂一个连接池。

[encro]

通常来说就是调用静态方法创建实例，然后调用实例的方法来修改、摧毁自身。

选择这样：

canvas= new canvas();
duck=new duck();
duck.setColor(red);
duck.run(speed);
duck.eat();
duck.die();
cavas.add(duck);


而不是这样：

canvas= new canvas();
duck=new duck();
addDuckToCanvas(duck,canvas);

更不要：

moveDuck(canvas,duck,speed)


为什么？因为实际情况可能是：

canvas= new canvas();
duck=new duck(color,speed,size,direction);
canvas.add(duck);

这是鸭子的运动由自己控制，而不是画布控制。

就如现实世界：

交警根据司机是否违规开罚单，司机自己管开车。

每个类做好自己的事情情况下，尽量减少外部条件依赖。

外部依赖越少，代码越好维护。

[CantSee]

直接 @Component 梭哈