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 のゲッター/セッターを配置するポイントは何ですか? なぜ C のゲッター/セッターを保持しないので、実装で役に立たないゲッター/セッターを実装する必要がなくなるのでしょうか?

私が言われている議論は、私たちはこのようにするのに慣れているので、私たちはこのようにやっているということです.

そのため、メソッドでタイプ I (インターフェース) のオブジェクトを処理するときは、常に null チェックを行う必要があります。

4

1 に答える 1

0

インターフェイスに A、B、D、および E のゲッター/セッターを配置するポイントは何ですか? C のゲッター/セッターを保持しないのはなぜですか?実装で役に立たないゲッター/セッターを実装する必要はありません。

おっしゃるとおり、デザインが悪いように見えます。get/set C を持つ基本インターフェイスと、get/set A/B を含むものと get/set D/E を含むものを持つ 2 つのサブインターフェイスがあるはずです。

私が言われている議論は、私たちはこのようにするのに慣れているので、私たちはこのようにやっているということです.

この引数は、既存のアプリケーション クライアントが API の上に構築されている可能性がある既存のエンタープライズ アプリケーションとの下位互換性を維持するために、レガシー エンタープライズ アプリケーションで一般的です。既存のアプリが壊れない場合、クライアントにアップグレードするよう説得しやすくなります。

ただし、アプリをこのように実行するケースが有効なものであることを確認するために、より詳細な情報を取得することをお勧めします。要件を満たしている可能性がありますが、より優れたアーキテクチャを備えています。

于 2013-01-31T06:10:03.350 に答える