Как смоделировать различную информацию в объект?

Question

Я хочу, чтобы пользователь выбирал различные способы оплаты. Поэтому у меня есть класс, описывающий способ оплаты.

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

    //Constructors, Accessors... 
} 

Теперь у меня есть компонент, удерживающий выбор пользователя

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

Мой вопрос, как лучшая модель в PaymentInformation класс. Проблема, с которой я сталкиваюсь, заключается в том, что в зависимости от выбранного метода PaymentMethod информация для хранения в этом объекте может быть очень различной.

Например, для способа оплаты "кредитной карты", нам нужен

• номер кредитной карты
• код карты безопасности
• владелец
• дата истечения срока действия

Для оплаты по PayPal нам нужно (я действительно не знаю, просто чтобы понять).

• Адрес электронной почты

Для оплаты с помощью прямого дебета мы должны

• Владелец
• номер счета
• кредитное учреждение

Вот несколько решений я придумал до сих пор:

Дизайн трех различных классов. Пусть OrderBean имеют три разные ссылки и проверяют, что правильная ссылка заполнена в соответствии с selectedPayment.

Пусть эти три класса наследуют от общего базового класса или интерфейса и проверяют фактический тип одной ссылки, которая находится в OrderBean.

Сделайте один класс для всех платежных данных вместе с полем PaymentMethod и дайте классу проверить его элементы в соответствии с самим PaymentMethod.

И я уверен, что могут быть и другие способы.

Так что же это лучший способ реализовать это?

Answer 1

PaymentInformation и PaymentMethod тесно связаны. По-моему paymentInformation должно быть полем PaymentMethod. Класс PaymentMethod должен предлагать методы для заполнения своего внутреннего paymentInformation. Класс PaymentInformation может быть внутренним классом PaymentMethod, чтобы выразить корреляцию.

Можете ли вы представить себе, как использовать PaymentInformation, например, хранить его без соответствующего способа оплаты?Если да, вы можете создать общий interface для PaymentInformation, но в противном случае вам не нужно это делать.

--EDIT--

Что касается ваших неоднократных вопросов о том, где для проверки фактического типа оплаты для того, чтобы обеспечить Платежное конкретное поведение:

пытается переложить на собственном страхе и риск от вашего внешнего кода объект, тем самым делая остальную часть вашего агрегированного типа платежного типа. Вместо проверки на instanceOf, а затем что-то сделать, вы должны вызвать метод paymentInformation (например, paymentInformation.createReport(), paymentInformation.issueBill()) и т. Д.), И пусть фактический метод оплаты + информация самостоятельно примет решение о том, как вести себя , Потому что кто еще должен знать лучше, чем фактический объект?

Answer 2

Я бы не создал класс PaymentMethod, вы могли бы создать интерфейс PaymentInformation с помощью метода getPaymentMethod, который должен переопределить каждый класс, реализующий этот интерфейс. Ваш PaymentMethod будет enum (CREDIT_CARD, PAYPALL, ...).

Каждая реализация теперь имеет требуемую информацию.

В вашем OrderBean вы можете получить PaymentMethod по телефону paymnetInformation.getPaymentMethod(), если необходимо.