softwarer Интеграторвот один из возможных вариантов
Хм. Понятно :) Комментарии:

1) Если честно, я бы не назвал это решение "Через функторы это разруливается естественным способом" (c) Конструирование прокси-объекта - прием нормальный, но "естественным" я бы назвал решение именно через функтор как таковой, решение, опирающееся на идею функтора. Здесь функтор играет сугубо вспомогательную роль; любая сущность, которая умеет вызвать функцию по указателю, но не является функтором, справится ничуть не хуже.

Что именно это за сущность - предлагаю не уходить в абсолютно теоретические обсуждения. Просто "математически": либо все на свете является функтором, либо примененный аналогично не-функтор справится ничуть не хуже.

2) Далее - придирка к самому "естественно". Я соглашусь, что решение выполнено аккуратно, и - не готов обсуждать, но не удивлюсь, если для конкретной реализации компилятора C++ оно имеет весомые преимущества. Но вариант с inner объектами - все внутри одного класса - мне представляется именно что "естественным" для решения задачи "несколько внутри одного", нежели поддержка вспомогательного списка вспомогательных объектов, "обманывающих" кнопку.

Согласен, что пример не самый лучший для демонстрации функторов. Хотлось максимально приблизиться к тому что цитировалось на Java. Конечно более интересноым было бы решение полностью на шаблонах. Если эта тема интересна, можно продолжить обсуждение ;) Код будет правда менее "рантаймным", но с доруго стороны часто это и не нужно ;)

Всё таки не удержался привести ещё один пример функторами - правда у же не самописными ;)

softwarer ИнтеграторВсё таки не удержался привести ещё один пример функторами - правда у же не самописными ;)
Тем не менее, это ровно такое же конструирование вспомогательных объектов. По-прежнему буду утверждать, что такое решение менее "естественно", чем явная реализация того же самого. Позволю себе усложнить задачу - требуется еще и переключать обработчики во время жизни объекта (в зависимости от ситуации присваивать тот или другой вызов). Тогда скрытое создание объектов тут же обернется против программиста.


Честно говоря не понимаю в чём вы видите проблему. Приведите пожалуйста соответвующий код, причём наставиваю на С++ - в Java есть свои фичи и вести разговор по-моему конструктивнее если конкретиризоваться на одном синтаксисе ;)


Давайте забудем, что в яву вроде как добавляют шаблоны. Чем этот код принципиально отличается от

?

Лично я - считаю такое плохим тоном, но объективности ради - делается.

Принципиально всё сводится к одному и тому же но симантически код с функторами предельно понятен - любому вменяему Сишнику сразу очевидно что делается, а невнимяемый думаю догадается по крайней мере до смысла конструкции ;)

Кстати маленькое дополнение:

Почему вас не смущает код


void func(int nVal) {
// ...
}

int main() {
void (*fn)(int);
fn = func;
// ....
}

и смущает что создаются какие-то дополнительные объекты если вместо указателя на функию применяются функторы ?

Может стоит посмотреть на функуторы просто как на продвинутые указатели ;) ?

Я не хочу спорить что kecit - интерфейсы или функторы, т.к. это разные вещи и в каждом случае отдельно решается что удобнее и гибче...