实现具有null属性的抽象类

Question

In the context of my current project, I am asked to implement something like this:

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.
    }

}

So, basically, only the C property makes sense for both of the implementations.

What is the point to have the getters/setters for A, B, D and E in the interface? Why just not keep the getter/setter for C, so we don't have to implement the useless getters/setters in the implementations?

The argument that I am told is: we are doing like this because we are used to do it this way.

So when we process some objects of type I (the interface) in our methods, we have to make null checks all the time.

Answer 1

What is the point to have the getters/setters for A, B, D and E in the interface? Why just not keep the getter/setter for C, so we don't have to implement the useless getters/setters in the implementations?

As you say, it does look like a bad design. It seems there should be a base interface that has get/set C, and two sub-interfaces with one containing get/set A/B, and the other containing get/set D/E.

The argument that I am told is: we are doing like this because we are used to do it this way.

This argument is common for legacy enterprise applications to keep backward compatibility with existing apps clients may have built on top of an API. It makes it easier to convince clients to upgrade if their existing apps won't break.

However, you might want to get more detail to make sure the case for doing your app like this is a valid one - "because we used to do it this way" sounds pretty evasive to me, and doesn't really help evaluate other options that may meet the requirements but with a better architecture.