- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
static class CheckBoxCellRenderer extends JCheckBox implements ListCellRenderer {
public Component getListCellRendererComponent(JList list, Object value, int index, boolean isSelected, boolean cellHasFocus) {
if (value instanceof CheckBoxListElement) {
CheckBoxListElement cblel = (CheckBoxListElement) value;
if (isSelected) {
setBackground(list.getSelectionBackground());
setForeground(list.getSelectionForeground());
}
else {
setBackground(list.getBackground());
setForeground(list.getForeground());
}
setSelected(cblel.isSelected());
setText(cblel.getText());
return this;
}
else {
throw new RuntimeException();
}
}
}
Follow us!
>setForeground(list.getSelectionForegrou nd());
Всё это решается путём вызова нативного метода setBackgroundToBackgroundFromColorToSame Color(list);
он еще и вложенный
Я бы даже instanceof в такой ситуации не делал, сразу бы кастил.
Еще интересно было бы увидеть как Java компилятор разобрался бы с неожиданным return.
Если там написать другой тип, то код не скомпилится, т.к. класс не будет реализовывать интерфейс ListCellRenderer, метод интерфейса будет перегружен, но не определён.
> как Java компилятор разобрался бы с неожиданным return
и что в нём такого неожиданного? вы вздрогнули?
Неожиданный потому, что функция формально должна вернуть значение в конце. Но если ее дословно переписать в байткод, то в конце получется недосягаемый участок с return <и тут не понятно что>. Т.е. компилятору нужно будет сообразить, что return, который написал программист не нужен, и его нужно выбросить, и точно такой же вставить вместо мертвого кода вконце.
нет, очень многие наступают на грабли, реализуя equals(MyClass) вместо equals(Object)
> функция формально должна вернуть значение в конце
функция может вернуть значение когда угодно. Никаких недосягаемых участков кода я не вижу.
Попробуйте оценить сами абсурдность обратного поведения. Тот, кто вызывает метод интерфейса, ожидает, что интерфейс будет работать с каким-то более общим типом к примеру, Object. Узкоспециализированный метод не может служить реализацией, ибо он нарушает контракт.
А перегружать методы с какой версии можно было?
все-таки лучше было бы.
Компилятор сгенерирует код, который вызовет Если да, то в чем смысл перегрузки?
Идея в том, что CheckBoxCellRenderer будет передаваться в качестве отрисовщика элементов списка стандартному компоненту Swing. При этом для стандартного компонента Swing этот отрисовщик будет представляться как реализация интерфейса ListCellRenderer, у которого есть только один полиморфный метод getListCellRendererComponent(JList, Object...). Поэтому о поиске наиболее подходящей функции речь тут даже не идёт. Перегрузка в Java работает примерно так же, как она работает в C# и С++.
> при наличии метода принимающего A
в том то и суть, что метод принимает не A, а интерфейс С. Об A он и знать не знает. И вызываться будут методы C, а не перегруженные методы A.
http://pastebin.com/zB4HjmkT
Мне такой подход видится логичным. Если в Java это не так... то можно только руками развести.
http://ideone.com/TbuuO
Наверное, он не понимает зачем и как были придуманы интерфейсы
CheckBoxListElement - явно какой-то user class, что-то там инкапсулирует и используется тут как модель.
RuntimeException "бросать" - явно плохой стиль, лучше убрать extends JCheckBox и сделать JToggleButton в виде
композитного объекта, а экстендить DefaultListCellRenderer, тогда логично в else-ветке просто написать:
return super.getListCellRendererComponent(list, value, index, isSelected, cellHasFocus) и голову себе не ломать...
Если JCheckBox не наследовать в этом классе, всё равно скорее всего придётся наследовать в ещё одном внутреннем, чтобы переопределить некоторые методы. И ничему это не поможет, класс и так внутренний и скрытый.