Java 实现具有空属性的抽象类

在我当前项目的背景下，我被要求实现如下内容：

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的getter/setter有什么意义？为什么不保留C的getter/setter，这样我们就不必在实现中实现无用的getter/setter了

我被告知的论点是：我们这样做是因为我们习惯了这样做

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

在接口中使用A、B、D和E的getter/setter有什么意义？为什么不保留C的getter/setter，这样我们就不必在实现中实现无用的getter/setter了

正如你所说，它看起来确实是个糟糕的设计。似乎应该有一个具有get/set C的基本接口，以及两个子接口，其中一个包含get/set a/B，另一个包含get/set D/E

我被告知的论点是：我们这样做是因为我们习惯了这样做

对于遗留企业应用程序来说，此参数很常见，它可以保持与客户端可能在API之上构建的现有应用程序的向后兼容性。如果客户现有的应用程序不会崩溃，那么就更容易说服客户升级

---

然而，您可能需要获得更多的细节，以确保这样做的应用程序是有效的——“因为我们以前是这样做的”对我来说听起来很含糊，并且实际上无助于评估其他可能满足要求但具有更好架构的选项。

取决于a-E的本质，但正如你所说，这看起来是个糟糕的设计。可能是他们想同时存储在一个列表中并访问所有变量？我以前也曾采取过类似的懒散方式。.“我们这样做是因为我们习惯了这样做”是一个循环论点。问一个真正的原因。但是如果有很多这样的事情，肯定有人应该引入一个包含所有空方法的抽象类，这样你只需要扩展它并覆盖你需要的。实际上是一个适配器。是

getA（）：Stringjava？