Унаследовал некоторые плохие обобщения Java.

Это неприятная проблема, и, возможно, дизайн просто плохой.

Я пишу набор простых компонентов диаграмм (круговые, гистограммы и линейные диаграммы) и задыхаюсь от некоторых общих вещей. Заранее я уверен, что существует множество Java API для выполнения именно того, что я пытаюсь сделать здесь (создание диаграмм / отчетов и т. Д.), Однако меня это интересует как общая проблема с обобщениями; тот факт, что он включает в себя диаграммы и компоненты отчетности, тривиален.

Каждая диаграмма наследуется от общего абстрактного базового класса Диаграмма :

public abstract class Chart<T extends ChartComponent>
{
    private List<T> components;

    // ...rest of the Chart class
}

Причина, по которой у нас есть T extends ChartComponent , заключается в том, что каждый подкласс диаграммы будет состоять из 1+ так- называемые компоненты диаграммы (столбцы, линии, секторы и т. д.):

public abstract class ChartComponent
{
    private Color color;

    // .. rest of ChartComponent class
}

public class PieWedge extends ChartComponent
{
    double wedgeValue;

    // ... rest of PieWedge class
}

Объединение этого дизайна:

public class PieChart extends Chart<PieWedge>
{
    // ... thus its list of ChartComponents is actually a List<PieWedge>
}

Таким образом, PieChart не является общим (и не должно be) и всегда имеет тип Chart .

Ранее у меня была такая же настройка для столбчатых и линейных диаграмм, которые были определены как BarChart extends Chart и LineChart extends Chart соответственно (поскольку столбчатая диаграмма состоит из 1+ групп столбцов, а линейный график состоит из 1+ линий).

Теперь я хочу еще больше абстрагироваться от гистограмм и линейных диаграмм.Обе эти диаграммы фактически построены на декартовом графике (x, y) с осями x и y; это в отличие от круговой диаграммы, которая не строится относительно каких-либо таких осей.

В идеале я хотел бы создать новый абстрактный класс под названием CartesianChart , который расширил бы Chart , а затем имел бы BarChart и LineChart одновременно расширить CartesianChart . Этот новый CartesianChart представит новые свойства ( xAxisLabel , gridTurnedOn и т. Д.), Которые логически применимы к гистограммам / линейным диаграммам, но не к круговым диаграммам.

Кроме того, чтобы ограничить CartesianChart , чтобы он мог иметь только chartComponents типа BarGroup или Line (а не PieWedge ), я хотел бы создать новый тип компонента диаграммы, например CartesianComponent extends ChartComponent , а затем BarGroup / Line расширить его. Это предотвратит компиляцию такого кода:

LineChart lineChart = new LineChart();
lineChart.addLine(new PieWedge());

Поскольку Line расширяет CartesianComponent , но PieWedge расширяет только ChartComponent . Таким образом, прежде чем перейти к моей проблеме, у нас есть следующая иерархия наследования:

Chart
    CartesianChart
        BarChart
        LineChart
    PieChart

ChartComponent
    CartesianComponent
        BarGroup
        Line
    PieWedge

PieChart extends Chart<PieWedge>

CartesianChart extends Chart<CartesianComponent>

BarGroup extends CartesianComponent
Line extends CartesianComponent

BarChart extends CartesianChart<BarGroup>
LineChart extends CartesianChart<Line>

Проблема с этой настройкой заключается в том, что и на BarChart , и на LineChart возникает ошибка компилятора с жалобой на то, что CartesianChart не является универсальным. В этом есть смысл, но я не уверен, что могу сделать, чтобы это исправить!

Если я попытаюсь заново определить CartesianChart :

public abstract class CartesianChart<T extends CartesianComponent> extends Chart<CartesianComponent>
{
    // ...
}

, я получаю ошибки компилятора "несоответствие типов" на всем протяжении кода моей гистограммы / линейной диаграммы. В каждом случае ошибки указывается, что ожидаются аргументы типа List , но вместо этого найдено List или List и что они не подходят для замены.

Надеюсь, это быстрое исправление где-нибудь в определении класса CartesianChart и / или CartesianComponent . В противном случае мне, возможно, придется переделать всю библиотеку диаграмм. В любом случае, меня интересуют все предложения, кроме вроде « Эй, почему бы вам просто не попробовать JFreeCharts или ...». Опять же, меня здесь интересует решение, поскольку оно связано с решением широкого круга аналогичных проблем с универсальными шаблонами; тот факт, что это связано с отчетностью / составлением графиков, тривиален.

Заранее благодарим за любую помощь!