实现具有空属性的抽象类答案

【问题标题】：Implementing an abstract class with null properties实现具有空属性的抽象类
【发布时间】：2013-01-15 04:18:36
【问题描述】：

在我当前的项目中，我被要求实现这样的东西：

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（接口）的对象时，我们必须一直进行 null 检查。

【问题讨论】：

取决于 A-E 本质上是什么，但就像你说的那样看起来很糟糕。可能是他们想将两者都存储在列表中并访问所有变量？我以前也有过这样的偷懒……
“我们这样做是因为我们习惯这样做”是一个循环论证。问一个真实的原因。但是如果有很多这样的事情，那么肯定有人应该引入一个包含所有空方法的抽象类，这样你只需要扩展它并覆盖你需要的那些。实际上是一个适配器。
是getA():String;java吗？

标签： java oop interface abstract-class

【解决方案1】：

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

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

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

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

但是，您可能希望获得更多详细信息，以确保这样做您的应用的理由是有效的 - “因为我们曾经这样做”对我来说听起来很回避，并没有真正帮助评估可能满足要求但具有更好架构的其他选项。

【讨论】：