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

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

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

Answer 1

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

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

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

这一论点对于遗留企业应用程序来说很常见，以保持与客户端可能在API之上构建的现有应用程序的向后兼容性。如果客户的现有应用程序不会中断，则可以更轻松地说服客户升级。

但是，您可能希望获得更多详细信息，以确保像您这样的应用程序的案例是有效的 - “因为我们过去常常这样做”对我来说听起来相当回避，并没有真正帮助评估可能符合要求但具有更好架构的其他选项。

实现具有null属性的抽象类

1 个答案: