Элемент броска в операторе Java For Each
Действительно ли это возможно (или даже желательно) бросать элемент, полученный от для каждого оператора в самом операторе? Я действительно знаю, что каждый элемент в списке будет иметь тип <SubType>.
Т.Е.:
List<BaseType> list = DAO.getList();
for(<SubType> element : list){
// Cannot convert from element type <BaseType> to <SubType>
...
}
вместо:
List <BaseType> list = DAO.getList();
for(<BaseType> el : list){
<SubType> element = (<SubType>)el;
...
}
4 ответа
Вы действительно знаете, что каждая запись будет подтипом? DAO просто должен выполнить контракт List , и если вы предполагаете подкласс, то я думаю, что где-то что-то не так. Возможно, я бы больше сконцентрировался на правильном интерфейсе к DAO и по контракту вернул бы то, что вы хотите.
По всем причинам, указанным другими, вам не следует этого делать. Однако, если вы не можете изменить интерфейс, возможно следующее:
for (BaseType element : list) {
SubType subType = (SubType)element;
...
}
Насколько я знаю, это единственный способ сделать это и остаться по-настоящему безопасным по типу - т.е. не полагаться на стирание типа для выявления каких-либо проблем, которые могут возникнуть. не обязательно делать это намного позже.
Я понимаю, что это НЕ ТОЧНО то, что вы искали, но он справляется с преобразованием.
Если вы неравнодушны к коллекциям Google, вы можете обернуть список методом transform. В вашем случае это будет очень эффективно и полностью совместимо. Однако я бы поместил его в качестве метода-обертки, как предложил Брайан.
public List< SubType > fromDao ( )
{
// Put a comment for maintainer
// Lists from DAO always contain SubTypes
return
Lists.transform(
DAO.getList( ),
new Function< BaseType, SubType >( )
{
public SubType apply ( final BaseType from )
{
return (SybType) from;
}
};
}
Возможно, да! но не дай бог, зачем? Мои первые попытки в моей карьере сделали это, и я научился. Программирование на интерфейсы всегда имеет преимущество. Я всегда получаю вопросы от младших разработчиков о том, как обрабатывать случаи, когда только подтипы имеют требуемые методы / функции.
Скажем, класс Animal с подтипом Dog, имеющий метод bark (). Им нужна функциональность bark (). Фактическая проблема заключается в том, что они хотят, чтобы поведение животных при общении было не лаем (), а голосом животных (). Таким образом, новый подкласс Cat не требует meow (). А как насчет этого: - Моя собака стая, а кошки - нет. Поведение answer pack () не принадлежит одной собаке. Пакет - это другой аспект, передайте пакет всем объектам и попросите объекты присоединиться к пакету. (Шаблон посетителя / шаблон адаптера). Мой класс Wolf может использовать такое же поведение.
Я твердо отношусь к этому, нет, если это всего лишь один случай, я в порядке. Если ответ - я не уверен, тогда вам лучше перестраховаться, работая с интерфейсными контрактами.