web-dev-qa-db-ja.com

高効率結合のパッケージの回避

Java言語を使用してAndroidアプリケーションを開発します。静的分析の後、ツールは高効率の結合について警告します。

この警告の理由は何ですか？他のクラスで拡張されたAComModelについてですか？

ツールがそれらについて警告する4つのクラスがあります。論理的な質問をしたいと思いますが、何が問題なのか本当にわかりません。

public class AComModel {    
    public String GetComBusinessKey() {
        return "none";
    }
}


@JsonIgnoreProperties(ignoreUnknown = true)
public class StepOneCom extends AComModel {

    public View vi;
    public ArrayList<SummaryViewModel> lstSmr;

    @Override
    public String GetComBusinessKey() {
        return "shvi";
    }

}


@JsonIgnoreProperties(ignoreUnknown = true)
public class StepTwoCom extends AComModel {

    public ArrayList<AccViewModel> lstAcc;
    public SummaryViewModel c1;


    @Override
    public String GetComBusinessKey() {
        return "shvi";
    }

}


@JsonIgnoreProperties(ignoreUnknown = true)
public class StepThreeStepTwoCom extends AComModel {

    public StepFourCom stepFourCom;

    @Override
    public String GetComBusinessKey() {
        return "cashadvi";
    }
}
object-orientedcode-qualitycoupling
2
talhakosen

プロジェクトに完全なコードが表示されていないと、100％確実に判断することはできませんが、ツールが実行されていた場合 静的コード分析 、この警告は次のいずれかを示します。

  • StepOneComは、クラスView、ArrayList、SummaryViewModelのいずれの特定のメソッドとフィールドも使用しません。
  • StepTwoComは、クラスAccViewModel、ArrayList、SummaryViewModelのいずれの特定のメソッドとフィールドも使用しません。
  • StepThreeComはクラスStepFourComの特定のメソッドとフィールドを使用しません

または、上記にリストされているもののサブセット、または上記のすべてを一緒に。

不平を言っていることを正確に確認する最も簡単な方法は、上記の特殊なクラスを最も一般的なObjectに置き換えて（コンパイルを中断しない場合）、警告が消えるかどうかを確認することです。

これは、ウィキペディアで提供されている 効率的な結合 の説明に基づいています。

ソフトウェア開発の指標。クラスが知っているデータ型の数を測定します。

これには、継承、インターフェイスの実装、パラメータータイプ、変数タイプ、および例外が含まれます。

大きな効率的な結合は、クラスに焦点が合っていないことを示している可能性があります。また、結合されているすべてのタイプの安定性に依存するため、脆性を示している場合もあります。

簡単に言うと、コンパイルを中断せずに、特定の型をObjectなどの標準の型に置き換えることができれば、クラスがその特殊な型を認識する必要がないことを意味します。この「役に立たない知識」を導入すると、コードの保守が難しくなるだけです。

あなたのコードの読者は、なぜあなたがView、ArrayList、SummaryViewModel、AccViewModel、StepFourComを関与させたのかを推測しようとして頭を悩ませなければならないでしょう。単純な標準Objectでも同じように機能します。

私たちがそれに取り組んでいる間、スニペットで提示された方法、コードはおそらく 基本言語チュートリアル で提案された原則のさらに悪い違反をしているように見えることも指摘したいと思います。

  • 特定のメンバーにとって意味のある最も制限の厳しいアクセスレベルを使用します。正当な理由がない限り、privateを使用してください。
  • 定数以外のpublicフィールドは避けてください...パブリックフィールドは、特定の実装にリンクする傾向があり、コードを変更する際の柔軟性を制限します。

フィールドをパブリックにする必要があると200％確信していて、これを防弾で正当化できる場合を除いて、このようなコードのパブリックアクセス修飾子を将来の最悪の頭痛と悪夢の原因と考えてください。

public View vi;
public ArrayList<SummaryViewModel> lstSmr;

チュートリアルで提供されるガイダンスには理由があります。これは、この方法を試し、行き止まりであることを発見した複数のプログラマーの苦痛な経験に基づいています。

それほど露骨ではありませんが、コードスニペットのデザインの非常に滑りやすい部分は、継承の不当な使用です。継承は、それを使用するクラスに特定の追加の義務とリスクを課します。継承は、それがまさに必要なものであることを確認する必要があります。

これについて言及するのは、コードスニペットでのコードの記述方法が、AComModelがクラスではなくインターフェイスであり、デフォルトの実装を提供する代わりにGetComBusinessKeyを宣言する場合にも、同様に可能であるためです。 StepOneCom、StepTwoCom、StepThreeComは、クラスを拡張する代わりに、そのインターフェースを実装します。

3
gnat