实现具有null属性的抽象类

Question

在我当前的项目中，要求我实现以下内容：

interface I {

    getA():String;
    setA(String);
    getB():String;
    setB(String);
    ...
    getE():String;
    setE(String);
}

class I1 implements I {

    // These are basic getters/setters for A, B and C.
    getA(){}
    setA(String){}
    getB():String{}
    setB(String){}
    getC():String{}
    setC(String){}

    @Deprecated
    getD(){
        return null;
    }

    @Deprecated
    setD(String d) {
        // Does nothing.
    }

    @Deprecated
    getE(){
        return null;
    }

    @Deprecated
    setE(String e) {
        // Does nothing.
    }

}


class I2 implements I {

    // These are basic getters/setters for C, D and E.
    getC(){}
    setC(String){}
    getD():String{}
    setD(String){}
    getE():String{}
    setE(String){}

    @Deprecated
    getA(){
        return null;
    }

    @Deprecated
    setA(String a) {
        // Does nothing.
    }

    @Deprecated
    getB(){
        return null;
    }

    @Deprecated
    setB(String b) {
        // Does nothing.
    }

}

因此，基本上，只有C属性对于这两种实现都有意义。

在接口中具有A，B，D和E的吸气剂/设置剂有什么意义？ 为什么不保留C的getter / setter，而不必在实现中实现无用的getter / setter呢？

我被告知的论点是：我们之所以这样做，是因为我们习惯于这样做。

因此，当我们在方法中处理某些类型为I（接口）的对象时，我们必须始终进行null检查。

Answer 1

在接口中具有A，B，D和E的吸气剂/设置剂有什么意义？ 为什么不保留C的getter / setter，而不必在实现中实现无用的getter / setter呢？

就像您说的那样，它确实看起来像是一个不良设计。 似乎应该有一个具有get / set C的基本接口，以及两个子接口，其中一个包含get / set A / B，另一个包含get / set D / E。

我被告知的论点是：我们之所以这样做，是因为我们习惯于这样做。

对于旧版企业应用程序，此参数很常见，以保持与客户端可能已在API之上构建的现有应用程序的向后兼容性。 如果他们的现有应用程序不会中断，则可以更容易地说服客户进行升级。

但是，您可能想要获得更多详细信息，以确保像这样制作应用程序的情况是有效的-“因为我们以前是这样做的”对我来说似乎很规避，并且并没有真正帮助评估其他选项可能满足要求，但架构更好。