0

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

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 检查。

4

1 回答 1

0

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

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

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

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

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

于 2013-01-31T06:10:03.350 回答