データ転送オブジェクトのインターフェースを作成するのは良い考えですか、悪い考えですか？通常、オブジェクトは可変であると仮定します。
私の例はJavaですが、同様の概念を持つ他の言語にも適用できるはずです。
interface DataTransferObject {
String getName();
void setName(String name);
}
class RealDataTransferObject implements DataTransferObject {
String name;
String getName() {
return name;
}
void setName(String name) {
this.name = name;
}
}
もちろん、これは単純化された例であり、実際にはもっと多くのフィールドがあるかもしれません。
回答:
一般的な答えはnoです。特定の具体的な理由がない限りコードを追加しないでください。また、このようなインターフェイスの一般的な理由はありません。
そうは言っても、時には正当な理由があります。しかし、私が見たすべての場合で、これらのインターフェイスは部分的であり、共通のスーパークラスを与えずに多態的に使用したい複数のクラスによって共有される1つまたはいくつかのプロパティのみをカバーしました。典型的な候補は、Id何らかのレジストリで使用するNameプロパティ、またはユーザーに表示するプロパティです。ただし、Xを持つすべてのものを処理するコードが必要な場合には、この方法が役立ちます（メソッド（必要な場合のみ）XSourceを含むインターフェイスを作成するgetXだけですsetX）。
しかし、すべてのプロパティを含む、すべてのモデルクラスの個別のインターフェイスですか？それをする正当な理由は想像できません。悪い理由は、それを必要とする不適切に設計されたフレームワークです。エンティティEJBは、私が正しく覚えていれば、まさにそれを行いました。ありがたいことに、彼らは非常に悪いので、多くの牽引力を得ることはなく、EJB 3.0以来廃止されています
サイドノート：「値オブジェクト」という用語を使用してJava Beanを簡単なゲッターとセッターのみで記述することは避けてください- 通常は不変であるIDのないものとしての値オブジェクトのより一般的な定義と競合します。より良い用語はDTOまたはモデルクラスです。ただし、後者の場合、貧血ドメインモデルはアンチパターンと見なされることに注意してください。
インターフェイスは、インターフェイスを実装するクラスとそのクライアント間のコントラクトを定義します。これらは抽象化メカニズムとして使用されるため、クライアントは「特定の動作を持つもの」を操作できます。
したがって、「このインターフェイスを作成して使用する必要がありますか？」という質問に対する一般的な答えは、はい：はい、クライアントに意味的に関連する（単一の）概念を関連付けることができる場合。
たとえば、Comparableは優れたインターフェイスです。メソッドの1つのおかげで物事を比較できることを説明しているため、クライアントとして、比較可能なオブジェクト（ソートなど）の処理に興味があります。contrarioは、CoolStuffは彼らのような一般的な振る舞いがあるので良いインタフェースではありませんあなたはクールなオブジェクトは、特定の行動を持っていない認める場合（実際には、あなたが想像できるクールなオブジェクトを扱うているソフトウェアは、理にかなってbeCoolを方法）。
あなたの特定のケースでは、あなたのインターフェースは役に立たないと思います。誰が、いつ、どのように使用しますか？可変値ごとにインターフェイスを作成することはできません。そのため、メソッドの背後にある関連性のある興味深いプロパティを自問してください。
いくつかのメソッドを介してすべての可変値にアクセスできるオブジェクトを処理する場合は、Java Beanの概念と、クラスに規則を適用させる方法を確認してください。
マイケルが言ったように、特別な必要がない限り、インターフェースを追加しないでください。
テストは正当な理由の例です。実際のコラボレーターを呼び出すとき、それらが単に「値オブジェクト」である場合、実際のコラボレーターを使用することを好みますが、真の単体テスト分離のために、テスト用の偽オブジェクトを作成する必要があります。
「値オブジェクトのインターフェイス」は、アクセサーを呼び出すために使用されるものです。
アクセサのニーズに関するさまざまなポリシーを経験しました。一部の人々は可能な限り提唱し、他の人々は、書くコードの量を減らすことを禁止しています。
アクセサのいくつかの理論的根拠（または直接的な値の使用法）は次のとおりです。
個人的には、アクセサーの数を減らし、セッター（setName）が後で単純な影響以上のものになると予想されるときにそれらを使用することを推奨します。