Блог

У меня есть общий вопрос о разработке OO, который вытекает из модели гибернации.

Пример

платежная база (супертип)

 @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 может принимать экземпляр универсального объекта и по-прежнему сохранять правильный экземпляр.

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

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

Спасибо

-J

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

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

 String getPaymentType();
double getPaymentAmount();
  

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

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

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

PS: Вы сказали «…Поскольку Hibernate может принимать экземпляр универсального объекта и по-прежнему сохранять правильный экземпляр. » ==> Это, конечно, не полиморфизм. Я не знаю ничего о Hibernate, но я бы предположил, что для этого будет использоваться RTTI, и это похоже на полную противоположность полиморфизму. 🙂