Ссылочный тип Java с уникальностью подкласса и полиморфизмом

Question

У меня общий вопрос о дизайне ОО, связанный с Hibernate Model.

Пример

оплата - База (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
}

Наличный

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

  private String Paper
  private String Coins
  getters/setters

}

Работа с Hibernate не является проблемой (таблица для иерархии классов). Поскольку Hibernate может принимать общий экземпляр Object и при этом сохранять правильный экземпляр.

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

Есть ли что-то, чего мне не хватает, шаблон или что-то присущее Java, которое я могу использовать?

Спасибо

-J

Answer 1

Чисто из OO pov (точка зрения) вы должны пытаться извлечь интерфейс для транзакций типа CreditCard или Cash.Поэтому в идеале у вас не должно быть доступа к переменным подкласса X, если вы не можете реализовать его для подкласса Y (или лучше сказать хотя бы один другой подкласс).

Например, в этомВ этом случае я бы сказал, что вы можете иметь такие методы в Payment:

String getPaymentType();
double getPaymentAmount();

, которые реализуются всеми подклассами. По-другому .

Тогда вы получите истинный полиморфизм.

Если вам нужно получить доступ к чему-то конкретному, например, к «Бумаге или монете» «в других частях кода», то эти частикод должен import Cash вместо Payment.Это потому, что этот фрагмент кода специфичен для Cash транзакций и не связан с CreditCard, поэтому нет смысла извлекать некоторые специфические методы в Payment.

PS: Вы сказали "... так какHibernate может принимать общий экземпляр Object и при этом сохранять правильный экземпляр. "==> Это конечно не полиморфизм.Я ничего не знаю о Hibernate, но я предполагаю, что для этого будет использоваться RTTI, а это как раз противоположность полиморфизму.:)