Hello Stack Community,
Пожалуйста, объясните мне, каков наилучший способ обеспечить эффективную, элегантную универсальную типизацию, избегая при этом непроверенного назначения типов в следующей иерархии типов (я также привожу в пример мое текущее решение для типизации, но у меня сложилось впечатление, что Я где-то сильно провалился ...)
Интерфейс для операций DAO (здесь универсальный тип является очевидным и разумным решением, я думаю):
interface DaoInterface<T> {
T getData();
T setData(T t);
}
Абстрактный класс Dao для управления (общий класс и интерфейс имеют одинаковый общий тип):
abstract class DaoAbstractBaseClass<T> implements DaoInterface<T> {
/* mostly data and configuration handling, thus needed */
/* DAO operations ensured due to class generic parameter */
}
Фактическая реализация (Используемый тип, чтобы иметь возможность выводить и использовать типы, возвращаемые из интерфейса Dao):
class ConcreteDaoImplementation extends DaoAbstractBaseClass<ConcreteType>
А теперь некоторый абстрактный класс обслуживания, который содержит экземпляр Dao и использует его, поле сопоставляется с интерфейсом самого низкого уровня Dao (поскольку я заинтересован только в его использовании через операции интерфейса):
abstract class SomeServiceClass<T> {
private DaoInterface<T> dao;
}
И фактическая реализация услуги с конкретным типом (ConcreteType в примере):
class RealService extends SomeServiceClass<ConcreteType> {
/* Dao is now ConcreteType*/
}
Фактический DAO в реальной жизни обеспечивается внедрением зависимостей из внешнего мира.
Я думаю, что нас смущает то, что мы перехватили дженерики для самого низкоуровневого класса реализации просто для параметризации интерфейса абстракции верхнего уровня. Во-вторых, я думаю, что конструкция abstract class DaoAbstractBaseClass<T> implements DaoInterface<T> как-то наивна для генерирования класса просто для того, чтобы гарантировать тип реализации его интерфейса ... Может кто-то указать, что можно улучшить, или указать на некоторые умные внешние материалы? Буду благодарен!
Редактировать
Если кто-то нашел UML полезным, ниже приведен один, почти правильный с формальной точки зрения :)
