Я бы не сказал, что что-то было «дженерики против интерфейсов», у каждого свои потребности и цели. Использование общих параметров способом, упомянутым в оригинальном посте, служит нескольким целям. Это позволяет разработчикам определять базовые классы, которые составляют типы объектов поля класса. Используя это, разработчик может принять объекты класса в качестве параметров, которые они могут использовать для отражения фактических объектов и установки полей, или просто принять весь объект для установки в первую очередь. Проблема, которая связана с необходимостью объектов класса, а не с new T()
или так далее, известна как стирание типа .
Еще одно преимущество использования обобщенных типов заключается в том, что вам не нужно все время выполнять типизацию при использовании полей или методов из суперкласса - вы лично знаете их типы, но в Java эта информация о типах нигде не хранится. Дополнительным преимуществом является то, что все ваши методы получения / установки могут использовать общие параметры и предоставлять более разумный фронт другим объектам, которые основаны на том факте, что вы настроили специализированные поля в вышеупомянутом объекте.
Проблема с использованием интерфейсов для того же, что и дженерики, заключается в том, что вам нужны дополнительные методы для доступа к специализированным типам и их приведения перед их возвратом (или проверкой входящих типов, а затем установкой полей для объектов). Это делает дизайн более сложным и на самом деле совсем не помогает отделению.
Как я уже упоминал в комментарии, любые подклассы будут устанавливать параметры этого типа и ничего не предоставлять пользователю. Таким образом, у вас может быть что-то вроде class MegaSignupWizard extends SignupWizard<MegaSignupSection, MegaSignupObject, MegaSignupListener, MegaSignupView>
, и все остается совершенно корректным с MegaSignupWizard
, имеющим доступ к специализированным методам в классах без необходимости приведения. Теперь это круто:)