Лучший выбор дизайна: метод, возвращающий Object или передающий «Class <T>type» в качестве аргумента?

Question

Я столкнулся с этим во время объектно-реляционного сопоставления при создании сопоставителя строк (для сопоставления строки в> = 1 объектах).Я играл с DBUtils, и вам нужно реализовать интерфейс RowProcessor, чтобы иметь свой «собственный» маппер строк.Это сигнатура метода (1 из 4 таких методов, возвращающий один объект, список, карту и массив)

public <T> T toBean(ResultSet rs, Class<T> type) throws SQLException 
{
    //conversion logic
}

В Spring это сигнатура метода для отображения строк (только 1 метод):

Object mapRow(ResultSet rs, int rowNumber)
{
//conversion logic
}

Переход от метода DBUtil к объекту включает инстанцирование на основе отражения и слишком большое приведение типов, чтобы даже вывести объекты.

Spring кажется довольно простым (проще для сравнения).

Тогда возникает вопрос от гибкости дизайна, какой стиль лучше, и когда бы вы предпочли подход, основанный на отражении, по сравнению с последним (как указано выше)?Мне было просто любопытно, поэтому я подумал, что мне стоит потушить, чтобы получить некоторые идеи по этому поводу.Как вы думаете, почему DBUtils использовал подход, основанный на отражении?Какие-нибудь преимущества?

Answer 1

Использование отражения (или огромных операторов switch, или чего-либо еще) в этом случае имеет преимущество в том, что инкапсулирует небезопасный тип в одном месте. Абоненты указывают, что им нужно, и вот что они получают. Затем они могут продолжать работать с ним без каких-либо приведений и т. Д. Вам нужно только вручную проверить безопасность типов в этом одном месте, компилятор проверит это везде. Возврат объекта подразумевает, что вызывающие абоненты будут выполнять много приведений, каждое из которых может иметь ClassCastException и должно быть проверено вручную.