2

ドメイン エンティティにインターフェイスを使用する目的は何ですか?

私たちのプロジェクトでは、ドメイン エンティティのインターフェイスを使用しています。インターフェース内には、getter メソッドと setter メソッドしかなく、ドメイン ロジックさえありません。

このようなエンティティのインターフェイスを使用すると便利ですか? これは良い習慣ですか？

ありがとう。

4

3 に答える 3

6

それが良いアイデアである理由はたくさんありますが、実際にはプロジェクトの範囲によって異なります。

まず第一に、あなたの声明「...ドメインロジックでさえありません」。意味がありません。インターフェイスにロジックを含めることはできません。インターフェイスにロジックを含めることはできません。メソッドのシグネチャのみです。

これが行われる主な理由は、さまざまな用途のためにドメイン オブジェクトの複数の実装をサポートするためです。

ドメイン オブジェクトをインターフェイスにコーディングする理由:

  1. シリアライゼーション - ドメイン オブジェクトのシリアライズ可能なバージョンを作成したいが、そのコードをコア アプリに使用するコードと混同したくない場合があります。たとえば、Web アプリケーションの JSON にシリアル化するために使用する Person オブジェクトの実装があるとします。

  2. 共有 API - オブジェクトの実装が異なるパブリック API バージョンのコードを配布したい場合や、別のグループ (またはクライアント、ベンダー) がインターフェイスを利用できるようにしたい場合もあります。

  3. レガシー実装のサポート - 古いデータベースに、データを引き出すためのドメイン オブジェクトの別の実装を含むコネクタを構築する必要があるデータがあるかもしれません。

  4. テスト - コア クラスのインターフェイスを使用すると、テストに必要のないメソッドをすばやくスタブ化できるため、単体テストがはるかに簡単になります。

于 2013-02-05T19:18:20.550 に答える
2
  • この種のことが起こっているプロジェクトに取り組んだことはありません。
  • 典型的なデザインではありません。
  • それが良い習慣だと主張する人を聞いたり読んだりしたことはありません。
  • このような設計による利点は考えられません。
  • 私はそれが引き起こす迷惑を考えることができます。

データ オブジェクトのパブリック インスタンス フィールドにアクセスするときは、既に「コントラクトのプログラミング」を行っています。これが、Bean から取得するすべてのコントラクトです。アクセサーのレイヤーは何も追加せず、インターフェイスの別のレイヤーは言うまでもありません。Java Beans は、多くのデータが単なるデータであるという事実を認めており、それをコントラクトの背後にカプセル化することは、その有用性を損なうだけです。FP は、おそらく現存する中で最も優れたプログラミング パラダイムであり、この点を正しく理解しています。

質問するかもしれません (実際には @pst です :)、異なるエンティティが異なるシリアライゼーション戦略を実装するとどうなるでしょうか? 内部で異なる方法でデータを保存するとどうなりますか? おそらく、1つは非常に巧妙で、「パフォーマンス」の理由で多くのビットいじりを行います。

確かに、これが実際に必要とされるシナリオを想像することはできますが、逆の場合もあります。最初に、そのようなプロジェクトを行うことになることに気付き、次にBean に関するインターフェースを導入します。「もしかしたら、このクレイジーな要件はプロジェクトの途中で発生するかもしれない」という理由で、事前にそれを行うことはありません。そして実際には、これがほとんど起こらないことを明確に示しています。

また、そのような設計ではコンストラクターが問題外であることを忘れないでください。明確な理由もなく、ドメイン データのすべての部分に対して抽象ファクトリを作成するというプロジェクト全体のポリシーを適用することは、妥当な設計上の選択とは言えません。

于 2013-02-05T18:55:15.410 に答える
1

「インターフェースへのコード」というアドバイスをやりすぎている開発者を見てきました。彼らは、いつか便利になるかもしれない場合に備えて、常にインターフェイスを使用する必要があると考えています。

于 2013-02-05T19:02:21.807 に答える