对 Java 泛型的顶级理解

2023-06-10 09:43:30 +08:00
 mannixSuo
public abstract class ServiceA<SEAL extends SealServerServiceAbst<F, FPR, FSUP, FGD, FFE, FSTP, FMBF>,
        F extends ApplyCommon<FPR, FSUP, FGD, FFE, FSTP, FMBF>,
        FPR extends ApplyPartnerCommon<FMBF>, 
        FSUP extends SubPlanCommon, FGD extends CmContGoodCommon,
        FFE extends  FileCommon,
        FSTP extends  StampCommon, 
        FMBF extends  FileCommon,
        V extends  ApplyCommon<VPR, VSUP, VGD, VFE, VSTP, VMBF>,
        VPR extends  ApplyPartnerCommon<VMBF>, 
        VSUP extends  SubPlanCommon, VGD extends  GoodCommon,
        VFE extends  FileCommon,
        VSTP extends  StampCommon, VMBF extends  FileCommon>
        extends ServiceB< Apply,  ApplyMapper>
        implements TopService<V, VPR, VSUP, VGD, VFE, VSTP, VMBF> {
        // 一些业务逻辑
        }

前几天看到其他人写的一段代码,一眼给我看蒙了。 问了他才知道,因为和前端对接使用了 DTO ,FORM 两种参数类型,然后又和其他模块对接,又使用了一种参数类型。 他呢就把这几个参数抽象成泛型,在定义一个的抽象 service 如上,每种 service 处理不同类型的参数。 按我的理解,不管是前端交互还是给其他服务调用,就算参数不一样,一个 service 也能够进行处理啊。 他这个是不是过度设计了?

6708 次点击
所在节点    程序员
66 条回复
hidemyself
2023-06-10 09:46:50 +08:00
这种代码,我可能看一眼就放弃了,写的什么玩意儿
vitovan
2023-06-10 09:52:01 +08:00
@hidemyself #1 同意一楼,这代码如果不是生成的,而是手写的,那……只能甘拜下风望尘莫及五体投地顶礼膜拜以头抢地四仰八叉无话可说。
optional
2023-06-10 09:57:46 +08:00
这就是典型的为了 DRY 而 DRY ,我愿称之为,好看的屎。
tairan2006
2023-06-10 10:09:24 +08:00
过度设计了
totoro52
2023-06-10 10:21:59 +08:00
我甚至都不敢看完这代码,放弃,这要是改个参数 全炸
DTCPSS
2023-06-10 10:22:12 +08:00
看那一排排泛型约束我还以为看汇编呢
ns09005264
2023-06-10 10:22:54 +08:00
我在 bevy 游戏引擎里看到过大量的泛型设计,如果把一层层的抽象拍平了,可能也没有这么多的泛型同时在一起。
抽象设计烂才会同时出现这么多的泛型。
jwenjian
2023-06-10 10:23:59 +08:00
本来想进来学点知识的, 换个标题吧
olaloong
2023-06-10 10:30:14 +08:00
恐怖如斯,一眼看下去看岔了方括号的边界,还纳闷这怎么继承了 2 个类...
beneo
2023-06-10 10:36:13 +08:00
这个问题其实主要取决于具体的项目需求和项目规模。使用泛型确实可以让代码更加通用和灵活,但同时也可能增加代码的复杂度。

1. 在大型项目中,可能会有多种类型的参数,并且参数类型可能会频繁变化。这种情况下,使用泛型可以更好地解耦,使代码更加灵活,更易于维护。

2. 泛型的使用也使得代码的重用性更强。你可以定义一个方法处理多种类型的参数,而不需要为每一种参数都编写一个特定的方法。

3. 另一方面,过度的抽象可能会使代码更难理解和维护。太多的泛型可能会导致代码变得复杂和难以理解。同时,如果项目需求并不需要这么高的抽象级别,过度的设计可能会浪费开发和维护的时间。

总的来说,这个设计可能并非过度设计,而是取决于具体的项目需求和项目规模。如果这个设计能够提高代码的重用性、灵活性和可维护性,那么这种设计是有价值的。但如果这个设计增加了代码的复杂性,而没有带来足够的好处,那么这可能就是过度设计了。
yazinnnn
2023-06-10 10:36:14 +08:00
太蠢了, 这兄弟是不是不会写方法泛型?
luzemin
2023-06-10 10:36:42 +08:00
这叫滥用,不叫设计
PVXLL
2023-06-10 10:40:27 +08:00
还以为是讨论为什么不能 new T(),结果是是来看屎山中的屎山
nulIptr
2023-06-10 10:41:25 +08:00
一个 service 可能最终依赖这么多 service ,但一般也是用啥就注入进来当作属性就行了,没必要放继承里面
pursuer
2023-06-10 10:45:50 +08:00
虽然很长,但不复杂,只是必要性不高。类型体操还得看 typescript ,还有那些真的把模板用作元编程的 c++代码。。。
wanguorui123
2023-06-10 10:47:24 +08:00
JAVA 的泛型就是假泛型底层全是转为 Object ,C#的泛型才是真泛型
WIN2333
2023-06-10 11:04:01 +08:00
写的跟狗屎一样,一段代码你两分钟内很难理解,那基本上都是段垃圾代码了,代码是写给人看的,不是写成这个狗屎样子的
ghost024
2023-06-10 11:05:24 +08:00
我看了一下,其实很多泛型都是顶层抽象类的,我不理解的地方在于,为什么顶层的抽象类要写这么多的泛型,如果是需要在抽象类中定义抽象方法的返回参数就用 extends 的那些类型就好了,反正你的参数一定是这些类型或者这些类型的子类
gowk
2023-06-10 11:06:57 +08:00
完全没必要
组合优于继承
agagega
2023-06-10 11:07:57 +08:00
这对 Java 来说已经离谱了,但对 C++而言可能才刚刚开始,是时候给 Java 程序员一点小小的模板震撼了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/947486

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX