Я бы справился с этой ситуацией, построив фабричный метод, который производит правильный тип компонента Swing для любого заданного ReportElement
, например:
public static JComponent buildViewForReportElement(ReportElement element)
Внутри этого метода вам нужно будет на самом деле проверить объекты ReportElement
, чтобы увидеть, какой тип компонента построить. Эта проверка может означать проверку поля или флага на каждом объекте или может даже означать использование instanceof
для различения различных подклассов ReportElement
друг от друга.
Обратите внимание, что проверка таких объектов ReportElement
нарушает философию объектно-ориентированного программирования. Простое "объектно-ориентированное" решение потребовало бы, чтобы все ваши ReportElement
объекты имели buildView()
или getView()
метод, и поэтому ваш код GUI может просто вызывать getView()
для каждого ReportElement
, не зная, какая реализация getView()
действительно вызывается.
К сожалению, объектно-ориентированное решение заставляет вас смешивать код представления с кодом модели, и хорошо, что вы пытаетесь разделить их. Вот почему я бы рекомендовал не создавать код для построения GUI из объектов ReportElement
и вместо этого использовать фабричный метод для построения правильного представления для любого заданного ReportElement
.