【问题标题】:database structure and object oriented inheritance and multiple interfaces数据库结构和面向对象的继承和多种接口
【发布时间】:2013-07-10 06:11:37
【问题描述】:

所以在学习了一点关于接口编程和其他一些与继承相关的主题之后,我有另一个问题。

数据库通常是父子表。许多应用程序有 2-4 个层次结构,如推荐、推荐项、推荐计费项等和一些查找表。 现在,如果我将其建模为类,我将拥有

Class Referral
{
List<ReferralLineItems> rli;

}
Class ReferrralLineItem
{
List<ReferralBillingLineItem> rbli;
}

在这种情况下我可以在哪里应用接口或抽象类?

谢谢!

我见过很多资深架构师为 IReferralBLC 和 IReferralLineItemBLC 等创建接口来封装业务逻辑。这些接口几乎总是只有一种实现,如 ReferralBLC、ReferralItemBLC 等,那么为什么需要接口呢?

【问题讨论】:

    标签: oop design-patterns orm ooad


    【解决方案1】:

    就域实体而言,让它们实现接口的好处是值得商榷的。 Some even 将其视为反模式。

    您示例中的对象具有几个值得注意的特征,应该让您在在它们之上添加接口之前三思而后行:

    • 他们贫血,即没有任何行为。接口用于定义合约、对象之间的消息传递协议。如果没有要发送的消息,即没有要使用的行为,他们就会失去很大一部分兴趣。

    • 它们不太可能作为依赖项注入到其他对象中。您不需要在单元测试中模拟对象,因此通常体现在接口中的模拟和真实类的公共父抽象并不是真正需要的。

    【讨论】:

    • 很高兴了解不同的观点
    【解决方案2】:

    它们存在的原因与它们最初存在的原因相同,即松散耦合。您可以轻松地更改实现类,而无需修改那些接口(可能使用规则引擎来实现),加上测试,这始终很重要,这也用领域的语言描述了业务。另一方面,Object Relational Mapping 的概念已经在计算机科学界进行了讨论,并且仍在讨论中,因为对象模型和关系模型之间的conceptual difference 被称为Impedance Mismatch

    【讨论】:

    • @MeProgramming 不客气,但我不得不说我同意 guillaume31,因为这是我为域实体所做的(我不为它们使用接口) .我的回答主要是为了解释为什么有些建筑师这样做(而不是因为我这样做)。这并不意味着你永远不应该这样做,在一些有用的情况下它们是有意义的,总是使用最好的工具来完成这项工作。
    猜你喜欢
    • 1970-01-01
    • 2014-12-24
    • 1970-01-01
    • 1970-01-01
    • 2011-06-16
    • 1970-01-01
    • 2015-10-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多