因此，在学习了一些关于接口编程和其他一些与继承相关的主题之后，我有了另一个问题。
数据库通常是父子表。许多应用程序有2-4个层次的继承权，如推荐、引用、引用列表等和一些查找表。现在，如果我将其建模为类，我将拥有
Class Referral
{
List<ReferralLineItems> rli;
}
Class ReferrralLineItem
{
List<ReferralBillingLineItem> rbli;
}
在这种情况下，我在哪里可以应用接口或抽象类？
谢谢！
我见过许多资深架构师为IReferralBLC和IReferraLineItemBLC等创建接口来封装业务逻辑。这些接口几乎总是只有一个实现，比如ReferralBLC、ReferralItemBLC等，那么为什么需要接口呢？
就域实体而言，让它们实现接口的好处是有争议的。有些人甚至认为这是一种反模式。
示例中的对象有几个显著的特性，这些特性应该让您在添加接口之前三思而后行：
-
他们贫血，即没有任何行为。接口用于定义契约，对象之间的消息传递协议。如果没有信息可以发送，即没有行为可以使用，他们就会失去很大一部分兴趣。
-
它们不太可能作为依赖项注入到其他对象中。您不需要在单元测试中模拟对象，因此实际上并不需要mock和real类的公共父抽象，它通常体现在接口中。
它们存在的原因与最初存在的原因相同，即松耦合。您可以很容易地更改实现类，而无需修改这些接口（也许可以使用规则引擎进行实现），再加上测试，这始终很重要，这也用域语言描述了业务。另一方面，由于对象模型和关系模型之间的概念差异，即阻抗失配，对象关系映射的概念在计算机科学界已经被讨论过，并且仍在讨论中。