0

したがって、インターフェースへのプログラミングとその他の継承関連のトピックについて少し学んだ後、別の質問があります。

データベースは通常、親子テーブルです。多くのアプリケーションには、紹介、紹介アイテム、紹介ビリングアイテムなどといくつかのルックアップ テーブルのように、2 ～ 4 レベルの階層があります。これをクラスとしてモデル化すると、

Class Referral
{
List<ReferralLineItems> rli;

}
Class ReferrralLineItem
{
List<ReferralBillingLineItem> rbli;
}

この場合、インターフェイスまたは抽象クラスをどこに適用できますか?

ありがとう！

ビジネス ロジックをカプセル化するために IReferralBLC や IReferralLineItemBLC などのインターフェイスを作成するシニア アーキテクトを数多く見てきました。これらのインターフェイスには、ほとんどの場合、ReferralBLC、ReferralItemBLC などの実装が 1 つしかないのに、なぜインターフェイスが必要なのですか?

4

2 に答える 2

2

ドメインエンティティに関する限り、それらにインターフェースを実装させることの利点は非常に議論の余地があります. それをアンチパターンと見なす人 さえいます。

あなたの例のオブジェクトは、それらの上にインターフェースを追加する前によく考えなければならないいくつかの注目すべき特性を共有しています:

  • 彼らは貧血です。つまり、何の行動もありません。インターフェイスは、コントラクト、オブジェクト間のメッセージング プロトコルを定義するために使用されます。送信するメッセージがない場合、つまり使用する動作がない場合、彼らは関心の大部分を失います。

  • 依存関係として他のオブジェクトに注入される可能性は低いです。単体テストでオブジェクトをモックアップする必要がないため、通常はインターフェイスに組み込まれている、モック クラスと実際のクラスの共通の親抽象化は実際には必要ありません。

于 2013-07-10T13:18:10.283 に答える
1

それらは、最初に存在したのと同じ理由で存在し、疎結合です。これらのインターフェイスを変更せずに実装クラスを簡単に変更できます(おそらく実装にはルール エンジンを使用します)。また、テストは常に重要であり、ドメインの言語でビジネスを説明します。一方、オブジェクト リレーショナル マッピングのアイデアは、コンピューター サイエンスの世界で議論され、現在も議論されています。これは、オブジェクト モデルとリレーショナル モデルの概念的な違い(インピーダンス ミスマッチ) と呼ばれます。

于 2013-07-10T08:24:16.583 に答える