对 Java 泛型的顶级理解

[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 也能够进行处理啊。 他这个是不是过度设计了？

[byaiu]

写 c++的看起来异常的熟悉，这老哥肯定有 c++的背景，有可能还是 boost 教徒！

[RuLaiFo]

代码的终极奥义是简单易读，而不是强行设计，只有自己看得懂的就是装 x 。

[lingalonely]

这约束过头，令人窒息，希望这老哥不会被裁，不会离职，否则接收的人不知多花多少时间去挖死山，对是死山不是屎山

[Al0rid4l]

有没有必要是一回事, 写得好不好是一回事, 是否很难理解是另一回事.

前两个不了解具体业务不好评价, 有时候受限于语言表达能力, 泛型参数多也正常, 像 C# BCL 里十几个泛型参数的也不少

就是否很难理解这个问题而言, C++ Rust TS 选手看这类都很轻松吧

[litchinn]

初衷是好的，设计的不行，这个情况使用充血模型会好很多

[CodeCodeStudy]

既然写成这样，为什么不用 PHP 来写？