Хорошая причина, по которой это не должно быть сделано так, состоит в том, что вы не можете заставить подкласс реализовать определенный конструктор. Это очень очевидно для реализаций интерфейса, поскольку они не включают контракт для конструкторов.
И если бы у вашего реального или абстрактного класса BaseTable
был конструктор BaseTable(int columns)
, вымышленный подкласс VectorTable
с одним столбцом не потребовал бы его реализации и мог бы сделать что-то плохое, например
public VectorTable(int intialValue) {
super(1);
this.initialValue = initialValue;
}
Итак, во-первых, вы не знаете, реализует ли T
конструктор вообще, а во-вторых, вы не знаете, имеет ли конструктор ту же цель (, которую он действительно должен иметь в надлежащем коде !! )
Так что я думаю, что лучшее решение - переместить параметризованную часть из конструктора в отдельный (конечный?) Метод, создать экземпляр с конструктором по умолчанию и сразу же вызвать этот метод инициализации.
Вы можете подумать о реализации BaseTableFactory
, если хотите убедиться, что все подклассы BaseTable всегда инициализируются правильно.
Редактировать
И new T()
(создание конструктора по умолчанию) также невозможны, поскольку ни один класс не может быть принудительным для реализации доступного конструктора по умолчанию. Я все еще думаю, что фабричный образец - ваш лучший друг здесь.