具有子类唯一性和多态性的 Java 引用类型

发布于 2024-12-10 12:42:03 字数 1013 浏览 1 评论 0原文

我有一个源自 Hibernate 模型的一般 OO 设计问题。

付款示例

- 基本(SuperType)

@Entity
@Table(name = "PAYMENT")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn( name = "type", discriminatorType = DiscriminatorType.STRING)
@DiscriminatorValue("BASE")

public class Payment{

 private Product product;
 private Date date;
 private Customer Customer;
 getters/setters
}

信用卡

@Entity
@DiscriminatorValue("CC")
public class CreditCard extends Payment {
  private String Account
  getters/setters
}

现金

 @DiscriminatorValue("CASH")
public class Cash extends Payment {

  private String Paper
  private String Coins
  getters/setters

}

使用 hibernate 不是问题(每个类层次结构的表)。由于 Hibernate 能够接受通用对象实例并且仍然保留正确的实例。

我的问题集中在代码其他部分中多态性地使用支付。由于每个子类都添加了唯一的实例字段,这意味着我需要在 Payment 本身上删除这些子类字段,只是为了获得多态性的好处。这似乎不正确,因为每次我向子类添加新字段或新类型的付款时,我都会返回并向付款添加方法。

我是否缺少一些东西,可以使用 Java 固有的模式或东西?

谢谢

-J

I have a general OO design question that stems from a Hibernate Model.

Example

payment - Base (SuperType)

@Entity
@Table(name = "PAYMENT")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn( name = "type", discriminatorType = DiscriminatorType.STRING)
@DiscriminatorValue("BASE")

public class Payment{

 private Product product;
 private Date date;
 private Customer Customer;
 getters/setters
}

CreditCard

@Entity
@DiscriminatorValue("CC")
public class CreditCard extends Payment {
  private String Account
  getters/setters
}

Cash

 @DiscriminatorValue("CASH")
public class Cash extends Payment {

  private String Paper
  private String Coins
  getters/setters

}

Working with hibernate is not a problem (table per class hierarchy). Since Hibernate is able to accept a generic Object instance and still persist the correct instance.

My question is centered around working with the Payment polymorhically in other parts of the code. Since each subclass adds unique instance fields does that mean I need to stub out these subclass fields on Payment itself just to buy the benefit of polymorphism. This does not seem correct in that each time I add a new field to a subclass or a new type of payment I am going back and adding metohods to Payment.

Is there something I am missing, a pattern or somthing inherent to Java I can use?

Thanks

-J

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

○闲身 2024-12-17 12:42:03

纯粹从 OO pov(观点)来看,您应该尝试提取信用卡或现金类型交易的接口。因此,理想情况下,如果您无法为子类 Y(或者更好地说至少一个其他子类)实现子类 X 的变量,则不应有任何访问器。

例如,在这种情况下,我想说您可以在 Payment: 中拥有类似的方法

String getPaymentType();
double getPaymentAmount();

,这些方法由所有子类实现。 不同

然后你就得到了真正的多态性。

如果您必须在“代码的其他部分”访问特定的内容,例如 Paper 或 Coin,那么代码的这些部分应该导入 Cash 而不是 Payment。这是因为该代码段特定于 Cash 交易,与 CreditCard 无关,因此在 Payment 中提取某些特定方法没有意义。

PS:你说“......因为 Hibernate 能够接受通用对象实例并且仍然保留正确的实例。” ==>这当然不是多态性。我对 Hibernate 一无所知,但我猜想它会使用 RTTI 来完成此任务,这与多态性正好相反。 :)

Purely from OO pov (point of view), you should be trying to extract interface to CreditCard or Cash types of transactions. So ideally you shouldn't have any accessors to variables of sub-class X if you can not implement it for sub-class Y (or better to say at least one other sub-class).

E.g. in this case I would say you could have methods like these in Payment:

String getPaymentType();
double getPaymentAmount();

which are implemented by all sub-classes. Differently.

Then you get true polymorphism.

If you must access something specific like say Paper or Coin "in other parts of the code", then those parts of code should import Cash instead of Payment. This is because that piece of code is specific to Cash transactions and not related to CreditCard, so no point in extracting some specific methods in Payment.

PS: You said "...Since Hibernate is able to accept a generic Object instance and still persist the correct instance." ==> This of course is not polymorphism. I donno anything abt Hibernate but I'd guess that it would use RTTI to accomplish this, and that's like exactly the opposite of polymorphism. :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文