Oop 如何将不同的信息建模到一个对象中？

我想让用户选择不同的付款方式。所以我有一个类描述了一种支付方法

public class PaymentMethod {
    private int id;
    private String name;
    private String description;

    //Constructors, Accessors...
}

现在，我有了一个bean，由用户选择

public class OrderBean {
    private List<PaymentMethod> availablePayments;
    private PaymentMethod selectedPayment;
    private PaymentInformation paymentInfo;
}

公共类OrderBean{
可获得的私人清单付款；
私人支付方式选择支付；
私人支付信息支付信息；
}

我的问题是如何对

PaymentInformation

类进行最佳建模。我面临的问题是，根据所选的PaymentMethod，该对象中要保存的信息可能会非常不同

例如，对于“信用卡”付款方式，我们需要

• 信用卡号码
• 卡安全码
• 所有者
• 有效期

我们需要贝宝支付（我真的不知道。只是为了说明我的观点。）

• 电子邮件地址

我们需要用直接借记付款

• 所有者
• 帐号
• 信用机构

到目前为止，我提出了几个解决方案：

设计三个不同的类。让

OrderBean

有三个不同的引用，并检查是否根据

selectedPayment

填写了正确的引用

让这三个类从公共基类或接口继承，并检查

OrderBean

中一个引用的实际类型

为所有支付信息创建一个类，以及一个

PaymentMethod

字段，并让该类根据

PaymentMethod

本身检查其成员

我相信还有其他的方法

---

那么，实现这一点的最佳方式是什么呢？

PaymentInformation

和

PaymentMethod

密切相关。 在我看来，

paymentInformation

应该是

PaymentMethod

的一个字段。

PaymentMethod

类应该提供填充其内部

paymentInformation

的方法。

PaymentInformation

类可以是PaymentMethod的内部类，用于表示相关性

你能想出一个单独使用

支付信息的用例吗，例如，不使用相应的支付方法存储信息？如果是，您可以为
PaymentInformation
创建一个共享的
界面
，否则您不需要这样做

--编辑--

关于您反复提出的关于在何处检查实际付款类型以提供付款特定行为的问题：

尝试将责任从外部代码转移到对象，从而使代码的其他支付类型不可知。与其检查
实例，然后做一些事情，不如调用paymentInformation的方法（例如paymentInformation.createReport（）、paymentInformation.issueBill（）等），让实际的付款方法+信息自行决定如何操作。因为还有谁比实际对象更了解呢
 我不会创建一个类
PaymentMethod
，您可以创建一个接口
PaymentInformation
，其中包含一个方法
getPaymentMethod
，实现该接口的每个类都需要覆盖该方法。
您的
PaymentMethod
将是一个枚举（信用卡、PAYPALL等）

现在，每个实现都有您想要的信息

在您的
OrderBean
中，您可以通过调用
PaymentInformation.getPaymentMethod（）
在需要的地方获取
PaymentMethod
。
如果有人能提供更好的标题或更合适的标签，我将不胜感激。您的支付方式是：信用卡、paypall等吗？那么，
OrderBean
呢？我是否需要键入检查
PaymentInformation
的引用？CreditCardInfo
的
PaymentInformation实例与
PaymentInformation.getPaymentMethod（）.equals（CREDIT_CARD）
相比有什么优势？在我的解决方案中，您使用的是多态性。因此，您可以使用PaymentInformation，而不必真正关心它是否是Paypall、信用卡，。。。当使用instanceOf时，它通常是一个大的if语句，表示设计不好。互联网上有很多比我聪明得多的人提供的更好的解释。你必须将责任从外部代码转移到对象上。您应该调用
paymentInformation
的方法（例如
paymentInformation.createReport（）
，
paymentInformation.issueBill（）
）等），让实际的支付方法+信息自行决定如何操作，而不是检查
的
实例然后执行某些操作。因为还有谁比实际对象更了解呢？你应该把你的评论和其他答案结合到这个答案中！