web-dev-qa-db-ja.com

データクラスをリファクタリングしないようにするにはどうすればよいですか？

最近PMD 6.0.0にアップグレードし、「データクラス」としてフラグが付けられたいくつかのクラスを取得していますか？それはカプセル化を壊し、もろいデザインを作ると主張します（私はこのサイト 別の意見があります であることを理解しています）。

私たちのチームがPMDルールを無視するのではなく、先に進んでデータクラスをリファクタリングすることにしたとしましょう。残念ながら、 PMDのルールに関するドキュメント は私には不明確です。

データクラスのリファクタリングは、適切なデータ動作の近接性の復元に重点を置く必要があります。ほとんどの場合、これはデータに定義された操作をクラスに戻すことを意味します。他のいくつかのケースでは、クラスを完全に削除し、データを以前のクライアントクラスに移動することが理にかなっている場合があります。

「データ動作の近接性」とは何か、または「以前のクライアントクラス」とは何かを理解できません。たとえば、次のようなものがあります。

public class Person {
    private String name;
    private List<String> formerNames;
    private List<Food> favoriteFoods;

    //getters and setters
}

PMDが推奨するように、このデータクラスをリファクタリングするにはどうすればよいですか？

ルールが良いルールかどうかではなく、どのようなリファクタリングに見えるかに焦点を当てたいと思います。現時点では、このルールを許可するか除外するかはわかりません。

object-orienteddata-structuresrefactoringcode-qualitycode-smell
7
Thunderforge

このデータに依存するメソッドをこのクラスに再配置する。例えば：

out.showlist(listNameRymes(person.getName())); // Redesign it so this
person.listNameRymes(out);                     // can be done like this

ただし、これはメソッドを移動するだけではありません。問題の見方はまったく異なります。

手続き型のメンタリティを使用している場合は、詳細を自分の方に引き出し、1か所で制御したいとします。ゲッターはそれを可能にします。しかし、今ではさまざまなものの詳細を混ぜ合わせているため、それらを分離するのが難しくなっています。

オブジェクト指向の考え方を使用するときは、詳細を自分から押し出します。あなたは他のものをそれらに対処させます。むしろ、あなたがオブジェクトに何かをするように伝え、詳細を処理することを期待することを求めます。

このアイデアには多くの名前がありますが、私のお気に入りは tell、do n't ask です。

これは、データクラスに場所がないと言っているのではありません。ソフトウェアは広範囲に通信します。時々それは境界を越えて通信します。一部の境界では、メソッドを移動できません。一部は概念的なものです。しかし、あなたはまだコミュニケーションする必要があります。これは、データクラスが輝くときです。

ツールを聞くタイミングと無視するタイミングを学びます。確認することを覚えるのはより良いかもしれませんが、あなたはいつでも判断を下すのが得意です。

11
candied_orange