|
|
|||||
Регистрация: Apr 2010
Сообщений: 219
|
Адекватное количество обработчиков
Просьба к флеш-общественности разрешить спор.
Ситуация: есть некий интерфейс (кнопочки всякие, а не Interface), при клике (наведении и пр.) на каждую из них необходимо выполнять какие-то действия, часто схожие между собой. Суть спора. Я склонен считать, что на каждую такую кнопку необходимо вешать свой слушатель с обработчиком (в результате будет создано несколько методов). Мой оппонент предлагает использовать один слушатель на контейнере, внутри которого определять тип объекта, по которому клацнули и затем switch-case-ом по имени определять необходимые действия (т.е. всего один метод). Вот пример: Кто прав и почему? Последний раз редактировалось arkadattx; 21.03.2011 в 14:26. |
|
|||||
Мне удобно для каждой кнопочки создавать отдельный класс, который она наследуют от общего, оверрайдив обработчик для каждой, т.е. писать все это внутри класса кнопки. Удобно тем, что неважно знать где находится кнопка, можем кинуть ее в любой контейнер
__________________
... |
|
|||||
Modus ponens
|
За свитч-кейс убивать сразу, это заразно. Ято Ява-оптимизаторы такое любят, т.как в ней написать обработчик события - это цельный класс с методами и имплементациями и т.п. Во флеше обработчик - это всего одна функция! А свитч искажает логику программы, усложняет тестирование и вообще чтение, при том, что если и есть какая-то разница в производительности - она на столько минимальна, что вы ее никогда не увидите. И шансы за то, что в том же свитче в итоге будут сделаны лишние телодвижения, которые эту самую производительность снова просадят.
Т.е. сравните: function close_clickHandler(event:Event):void {} function open_clickHandler(event:Event):void {} // и function clickHandler(event:Event):void { switch (event.target) { case foo: break; case bar: break; default: trace("???"); } } Вот так вот.
__________________
Hell is the possibility of sanity |
|
|||||
Регистрация: Nov 2008
Сообщений: 528
|
Голосую против case-ов.
Это искусственная конструкция, возникающая потому что кому-то лень написать 2 лишних строки (хотя отдельные функции и быстрее и проще написать и проще потом читать). |
|
|||||
Регистрация: Apr 2010
Сообщений: 219
|
wvxvw, спасибо за объяснения.
В данном проекте подобный функционал никогда не будет переопределяться. default отсутствует. То что "попали в неизвестный обработчик" (я так понимаю что речь идет скорее о неизвестной части обработчика) - можно заменить конструкцией типа Таким образом мы уменьшаем количество возможных ошибок и гарантированном попадем в нужный участок обработчика. При таком условии есть у такого подхода еще недостатки? Александр Мостовой, Stargazer, спасибо за мнение, но хотелось бы больше конкретики и объективизма. Личные предпочтения каждого - дело такое... Не стабильны как мода. |
|
|||||
Modus ponens
|
Для начала, default не может отсутствовать, то, что вы его не написали, еще на значит, что его нет. Он есть всегда, хотите вы того или нет. А за возвраты из функции в непредвиденных местах можно, если еще шевелится, контрольный выстрел сделать - хуже не будет.
Нет, еще раз, в switch'e вы делаете предположение, что event.current таргет а) существует, б) не равен нулю. При том, что оба эти предположения могут не выполнится. Т.е. вы предлагаете 100% работающий вариант заменить 99% работающим вариантом, аргументируя это чем? Улучшением производительности? На микрон? А если компилятор окажется в силах (в будущем) заинлайнить код обработчика? Так вы только просадите производительность вашим свитчем, т.как его будет труднее разделить на части и заинлайнить в разные места по частям. Но это уже гости из будущего С другой стороны, написав свитч, вы усложните себе последующую разработку и сопровождение - опять же, такие жертвы только ради того, чтобы выиграть миллисекунду на вызове 1000 обработчиков?
__________________
Hell is the possibility of sanity |
|
|||||
Регистрация: Nov 2008
Сообщений: 78
|
С автогенерацией кода конечно на каждую кнопку отдельный слушатель намного удобнее / красивее, только имена придумать
По мне все зависит от архитектуры. А вот тут я бы сделала класс кнопок который диспатчил бы события - не клик, а свои (AppControlEvent), и диспатчил их в какой нибуть глобальный контейнер и такие -же события диспатчила бы по нажатию кнопок на клаве/прочих действий. Но это личные вкусы сформировавшиеся под давлением большого количества разнообразных контроллов в одном приложении которые валяются в разных парентах. |
|
|||||
Регистрация: Nov 2008
Сообщений: 528
|
Цитата:
Могу попытаться поподробнее. Зачем вообще пишутся функции (а также объекты, классы и т.д.)? Чтобы реализовать в них какой-то алгоритм и далее работать с этим алгоритмом как с некоей логической сущностью. Хорошие программы получаются только тогда, когда программист придерживается принципа, что классы, функции и т.д. не должны быть натулены как попало - а должны быть, по возможности, структурированы и разделены друг от друга. Чем меньше взаимосвязей тянется от одной логической единицы к остальным - тем это лучше. Ну и т.д. Не буду напоминать уж совсем очевидные вещи. Мораль вкратце: связи должны, по возможности, расходиться ровными аккуратными линиями, а не путаться клубками. Вернёмся к вашей ситуации. Совершенно классическая ситуация "событие-обработчик". Событие - это один элемент. Обработчик - это другой элемент. Логика подсказывает, что самым логичным будет просто напрямую связать один элемент с другим, ведь больше ничего и не нужно? Таким образом, связи в программе будут простыми и легко читаемыми: closeButtonClickHandler, settingsButtonClickHandler, ... и т.д. Всё просто и чётко. Мне нужно только ткнуть на имя функции в outline в FD и работать. Да и просто беглый взгляд по outline помогает тут же определить, чем занимается данный класс. Вы же для чего-то хотите ввести дополнительный элемент, с целью сперва обобщить те вещи, у которых нет ничего общего (!), а потом разгородить всё обратно при помощи case. То есть вы выполняете 2 противоположных действия - ради чего? Назовите хоть 1 архитектурный плюс данного решения (аргумент "мне лень написать лишний раз addEventListener" не принимается). В архитектуре мы видим очевидный минус: этот убер-обработчик имеет слишком ниточек, тянущихся к другим элементам системы. Если вы хотите добавить новый обработчик - вместо того, чтобы прописать ещё 1 функцию и сохранить код в чистоте - вы будете добавлять новый case с новым алгоритмом и каждый следующий case будет смотреться ещё более невыносимо, чем предыдущий, число ниточек будет расти и в итоге ваш обработчик окончательно превратится в помойку (чем он и был с самого начала, на самом деле). И вообще, если в case выполняется более 2 команд - то всё равно нужно делать отдельную функцию. При таком подходе вообще неясно на чём вы сэкономили. В начале я говорил, что хорошая функция должна быть некой логической сущностью. Так вот, данная функция - это не сущность, а помойка из сущностей. Резюмируем: -: логически не обосновано -: читать неудобно -: делает систему менее гибкой +: ??? Последний раз редактировалось Stargazer; 21.03.2011 в 17:37. |
|
|||||
Регистрация: May 2010
Сообщений: 543
|
Думаю не стоит использовать кейсы, ибо код становится нагроможденным и нечитабельным.
Особенно, в том случае если обработчики для ваших кейсов будут представлять собой не одну строку, как в примере (exit(), text(1), test(-1)), а целую конструкцию, и получится просто жесть типа private function onMouseEvent(e:MouseEvent):void { if (e.target is ISkinButton) { switch (e.target.name) { case "closeButton": case "exitButton": function(){ if(a == b){ while(x < arr.length){ // ......... } } } break; case "plusButton": text(1); break; case "minusButton": test( -1); break; } } } |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Ранее ратовал за switch/case. Ныне вдохновившись речами wxvxw и собственным опытом ратую против них в подобных конструкциях.
__________________
Тут мужик танцует и поёт про флэш |
Часовой пояс GMT +4, время: 12:06. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|