| « Интерфейсы в actionscript 2.0. Часть 1. Внешние модули | ООП и Flash. Часть 2. Хитрецы против ООП » |
ООП и Flash. Часть 3. О фанатиках
2006-11-23 18:26 , Рубрики: Flash Противники ООП часто говорят о том, что ООП делает проект слишком большим. Мол, это может растянуть разработку небольшого клиента на неопределенное время - и когда у одних уже все работает и ‘летает’, у других только-только приложение начинает обрастать функционалом и работает заметно медленнее аналога. Однако когда дело доходит до изменений, уже первые в ужасе начинают кричать, что теперь все надо переписывать (и ведь переписывают, надо отдать им должное), а вторые вносят изменения и продолжают работать. Но ведь и до изменений дело не всегда доходит.
Тут как раз всплывает проблема убежденных и ярых сторонников ООП - когда дело так никогда и не доходит до изменений, классы редко используются повторно, а излишняя гибкость, в конце концов, оказывается ненужной и запутывает самих разработчиков. А что может быть хуже запутавшегося разработчика?
Появляется вопрос, как не впадать в фанатизм, чтобы не получилось ‘ООП - за что боролись, на то и напоролись’?
Для начала было бы не лишним выявить в себе ‘фанатика’? Привожу несколько признаков, которые помогут обнаружить фанатизм даже на ранних стадиях. 
Особое внимание, пожалуйста, пункту пять. Проверь себя!
- Ваш девиз - все динамически, даже статическое GUI мы аттачим поэлементно, чтобы неповадно было.
- У вас можно задать практически все параметры, какие только мыслимы - от цвета фона приложения до размера и расположения любой буквы и кнопочки. В идеале это все грузится из внешнего конфигурационного файла.
- Вы свято следуете заповедям ‘высокое зацепление и низкая связанность’. У вас практически никто ни о ком ничего не знает - просто общество анонимных алкоголиков какое-то, а не приложение. Хотя с другой стороны все рассылают события о своем состоянии, так что между анонимными алкоголиками все-таки идет активное общение.
- Вы заранее думаете о будущем, стараетесь предусмотреть все возможные изменения и готовитесь к этому. Конечно, тратится время, но потом оно окупится сполна - пару строчек изменил и порядок.
- Иногда вы выделяете новый класс, интерфейс или делаете еще что-нибудь только потому, что так правильно. И вообще ‘так правильно’ и так ‘ОПП-шно’ часто встречаемый у вас аргумент.
- Рефакторинг проводите редко или никогда. Да и зачем, когда все изначально делаешь правильно?
- На построение архитектуры приложения у вас часто уходит много времени. Лучше сразу все продумать, чем потом исправлять. Составляете огромное количество UML-диаграмм, расписываете use-case-ы. В общем все делаете правильно.
- Вы используете рассылку событий всегда, даже в тех случаях, когда очевидна избыточность этого. Например, когда есть только один-единственный слушатель и реально можно использовать просто переданный единственный объект Delegate для обработки события. Иногда это правило распространяется только на текущее приложение, что связано со стремлением к единообразию в коде.
- Вы никогда не делаете public свойств. Можно сказать, что это принцип.
Выявив в себе фанатика, можно задуматься над этим. Впрочем, реальные фанатики вряд ли задумаются. 
Зато могут быть уверены, что они - большая редкость в среде actionscrtipt программистов.
Тем, кто все-таки задумался, напоминаю, что излишняя гибкость и дальновидность может сделать приложение, написанное на actionscript более медленным. А медленные приложения подрывают веру заказчиков в способности технологии flash.
И не надо забывать, что все-таки разработка на flash - это быстрая разработка, поэтому бывает жизненно необходимо отказаться от лишней гибкости и правильности в пользу скорости.
Но отказываясь, от каких-то ООП-ых фич, будет не лишним отдавать себе отчет в том, к чему это может привести, чтобы потом не было мучительно больно вставлять эти фичи в полу работающее приложение. А вдруг вы хитрец c зачатками фанатизма? И, конечно, отказ от чего-то очень индивидуален - для каждого приложения можно немного пересматривать свою систему ценностей и ориентиров.
В общем, использовать ООП или нет, и если использовать, то в какой мере, решать вам. И то делать этот выбор осмысленно или нет, тоже решать вам. Я же просто хочу напомнить, что всегда есть выбор.
Bookmark this article at
Трекбек адрес этой записи
URL трекбека (щелкните правой кнопкой мыши и скопируйте ссылку)
30 комментариев
Надо не думать - использовать ООП или не использовать. А надо думать, какую технологию использовать для создания приложения. Или какой фрэймворк. Ну и все проблемы, описанные выше, превосходно решает Flex (стоит лишь пожалеть о старом и недальновидном решении применения Flex 1/1.5 лишь для серверного компилятора с ужасным лицензированием) с его фрэймворком. Как бы надо оставить Flash тем, для кого он и предназначался: дизайнерам, мультипликаторам, художникам и программистам, которые пишут в кадрах (ведь ничего в этом плохого нет если речь идет о презентациях/мультиках).
2006-11-23 @ 20:27
Отличный цикл постов про ООП и Flash.
Не верю своим глазам. Я нашел человека, который пишет от том, что имеет прямое отношение к 10 из 24 часов в моих сутках
Константин - человек глубоко и далеко образованный, лично для меня вопрос о выборе технологии пока что не стоит (Flex не знаю почти) Вопрос скорее в том, как жить с Flash-ом, на котором много всего уже понаписано.
Лично у меня еще не было проектов, в которых использование ООП не было бы оправдано. Скажу честно, что интерфейсы реально не использовал, но практически по всем пунктам (и по теории ООП) пытался сделать что-то адекватное И это себя полностью оправдывало.
Не верю своим глазам. Я нашел человека, который пишет от том, что имеет прямое отношение к 10 из 24 часов в моих сутках
Константин - человек глубоко и далеко образованный, лично для меня вопрос о выборе технологии пока что не стоит (Flex не знаю почти)
Вопрос скорее в том, как жить с Flash-ом, на котором много всего уже понаписано.Лично у меня еще не было проектов, в которых использование ООП не было бы оправдано. Скажу честно, что интерфейсы реально не использовал, но практически по всем пунктам (и по теории ООП) пытался сделать что-то адекватное
И это себя полностью оправдывало.
2006-11-24 @ 00:27
мне быстрее выделить класс, чем через пять минут ломать голову, что же здесь происходит.
думаю вопрос в хороших инструментах... трудно в объектах писать в родном flash IDE да и долго.
да и технология, например в as3 подписаться на событие проще, чем использовать делегат в as2.
думаю вопрос в хороших инструментах... трудно в объектах писать в родном flash IDE да и долго.
да и технология, например в as3 подписаться на событие проще, чем использовать делегат в as2.
2006-11-24 @ 04:35
Читаю книжку "человеческий фактор" не удержался решил процетировать:
Качество, серьезно превосходящее запросы кончного пользователя, есть средство достижения высокой производительности.
пример японцы.
В японии компромисс между качеством и стоимостью не существует. Здесь почти все считают, что высокое качество приводит к сокращению стоимости
(Tajima and Matsubara 1984)
речь идёт о том качестве, которое разработчики добиваются для себя, своей личной мотиваци и самореализации.....
а борьба с этим это уже ошибка управления....
Качество, серьезно превосходящее запросы кончного пользователя, есть средство достижения высокой производительности.
пример японцы.
В японии компромисс между качеством и стоимостью не существует. Здесь почти все считают, что высокое качество приводит к сокращению стоимости
(Tajima and Matsubara 1984)
речь идёт о том качестве, которое разработчики добиваются для себя, своей личной мотиваци и самореализации.....
а борьба с этим это уже ошибка управления....
2006-11-24 @ 08:05
Ответ для Constantiner
Не все могут свободно выбирать, какую технологию использовать - некоторые как я, птицы подневольные. Как заказчик скажет, так и надо делать. Вот заказчик говорит - делаем на flash и пожалуйста.
Да, я знаю, сейчас ты скажешь, что это дело разработчика показать заказчику, что на самом деле он хочет использовать flex, но имхо не всегда это можно осуществить.
В общем, пока что я не готова оставить flash дизайнерам, мультипликаторам, художникам и программистам, которые пишут в кадрах. Ведь не случайно actionscript пришел к свой true объектно-ориентированной реализации.
И еще. Программист - это сначала просто программист, а потом уже программист на чем-то конкретном. И у чего-то конкретного может быть своя специфика. Пока я пытаюсь мириться со спецификой flash.
Не все могут свободно выбирать, какую технологию использовать - некоторые как я, птицы подневольные. Как заказчик скажет, так и надо делать. Вот заказчик говорит - делаем на flash и пожалуйста.
Да, я знаю, сейчас ты скажешь, что это дело разработчика показать заказчику, что на самом деле он хочет использовать flex, но имхо не всегда это можно осуществить.
В общем, пока что я не готова оставить flash дизайнерам, мультипликаторам, художникам и программистам, которые пишут в кадрах. Ведь не случайно actionscript пришел к свой true объектно-ориентированной реализации.
И еще. Программист - это сначала просто программист, а потом уже программист на чем-то конкретном. И у чего-то конкретного может быть своя специфика. Пока я пытаюсь мириться со спецификой flash.
2006-11-24 @ 10:50
Ответ для Slon_vsapogah
Спасибо за поддержку. Очень приятно, что то, что мы пишем на riapriority интересно и нужно людям.
А интерфейсы - очень полезная вещь. Например, при построении систем из большого количества отдельных модулей или при использовании объектов с похожим поведением, но совершенно различной логикой (когда наследование применить нельзя).
Спасибо за поддержку.
Очень приятно, что то, что мы пишем на riapriority интересно и нужно людям. А интерфейсы - очень полезная вещь. Например, при построении систем из большого количества отдельных модулей или при использовании объектов с похожим поведением, но совершенно различной логикой (когда наследование применить нельзя).
2006-11-24 @ 10:53
Ответ для agahov
В родном flash IDE просто невозможно что-то писать с ощущением хоть минимального комфорта. Вообще, если кто-то там пишет, то снимаю шляпу - это, действительно, очень трудно.
А еще в одной книжке написано 'Быстро, качественно, дешево. Выберите любые два пункта'.
Саша, только не надо говорить, что я призываю к снижению качества. Наоборот, если уделять должное внимание специфике технологии, качество должно только повышаться.
Лучше скажи, что ты ответил на пункт 5?
В родном flash IDE просто невозможно что-то писать с ощущением хоть минимального комфорта. Вообще, если кто-то там пишет, то снимаю шляпу - это, действительно, очень трудно.
А еще в одной книжке написано 'Быстро, качественно, дешево. Выберите любые два пункта'.
Саша, только не надо говорить, что я призываю к снижению качества. Наоборот, если уделять должное внимание специфике технологии, качество должно только повышаться.
Лучше скажи, что ты ответил на пункт 5?
2006-11-24 @ 10:59
А насчет пятого пункта все просто. Если ты прочитала и услышала где-то, что вот как-то вот так - это правильно. Но почему, ты точно не знаешь, да и в точности как там правильно - тоже не ведаешь, то и не стоит. Лучше на кошках тренироваться. Можно и на реальном проекте - если он позволяет.
А если же у тебя уже юольшой в этом опыт, ты все это делаешь на автомате, без усилий, четко знаешь что и к чему приводит - то почему бы не делать правильно ради правильности? Это определенный стиль. Утонченные манеры в повседневной жизни тоже чаще всего бесполезны. Но так или иначе на человека с действительно утонченными манерами, в котором это огранично, - приятно посмотреть. И общаться приятно.
А если же у тебя уже юольшой в этом опыт, ты все это делаешь на автомате, без усилий, четко знаешь что и к чему приводит - то почему бы не делать правильно ради правильности? Это определенный стиль. Утонченные манеры в повседневной жизни тоже чаще всего бесполезны. Но так или иначе на человека с действительно утонченными манерами, в котором это огранично, - приятно посмотреть. И общаться приятно.
2006-11-24 @ 12:15
Комментарий от: Евгений Н. [Посетитель] 
"Утонченные манеры в повседневной жизни тоже чаще всего
бесполезны. Но так или иначе на человека с действительно
утонченными манерами, в котором это огранично, - приятно
посмотреть. И общаться приятно."
- Все-таки добрался ты, Костя, до книг по психологии,
как планировал (может уже забыл свои слова, я помню).
Наверняка под чутким руководством Junik,
эксперта в психологии. :-)
Передаю вам всем свой привет, не скажу что сильно
скучаю, но вспоминаю ВСЕХ очень часто.
Пишите, в блоге, буду читать, удачи вам. :-)
бесполезны. Но так или иначе на человека с действительно
утонченными манерами, в котором это огранично, - приятно
посмотреть. И общаться приятно."
- Все-таки добрался ты, Костя, до книг по психологии,
как планировал (может уже забыл свои слова, я помню).
Наверняка под чутким руководством Junik,
эксперта в психологии. :-)
Передаю вам всем свой привет, не скажу что сильно
скучаю, но вспоминаю ВСЕХ очень часто.
Пишите, в блоге, буду читать, удачи вам. :-)
2006-11-24 @ 12:28
Ответ для Constantiner
Делать правильно ради правильности - это, действительно, определенный стиль. Это своего рода педантичность. И ясное дело, что со временем, уже лень задумываться о том, почему ты делаешь именно так, а не иначе. Но если человек 'четко знает что и к чему приводит', то он и понимает, какие вещи можно опустить без вреда (а то и с пользой) для приложения.
У меня пока не настолько большой опыт разработки, чтобы я могла себе сказать - 'Все, Юля. Теперь просто можно идти по протоптанной дорожке, не задумываясь ни о чем.' Мне пока интересно пробовать новое в стиле программирования. И меня действительно смущают аргументы типа 'так правильно и так более ООП-но'. Другое дело, аргументы типа 'так более правильно, потому что...' или 'так будет более стабильно работать, потому что...'
Делать правильно ради правильности - это, действительно, определенный стиль. Это своего рода педантичность.
И ясное дело, что со временем, уже лень задумываться о том, почему ты делаешь именно так, а не иначе. Но если человек 'четко знает что и к чему приводит', то он и понимает, какие вещи можно опустить без вреда (а то и с пользой) для приложения.У меня пока не настолько большой опыт разработки, чтобы я могла себе сказать - 'Все, Юля. Теперь просто можно идти по протоптанной дорожке, не задумываясь ни о чем.' Мне пока интересно пробовать новое в стиле программирования. И меня действительно смущают аргументы типа 'так правильно и так более ООП-но'. Другое дело, аргументы типа 'так более правильно, потому что...' или 'так будет более стабильно работать, потому что...'
2006-11-24 @ 12:50
Так это и был мой ответ на пятый пункт
качество оно не только функциональное
совпадение результата со всеми требованиями.
Качество, также бывает эстетическим, со временем начинаешь чувствовать ООП стиль, который обязательно оборачивается:
хорошей структурой - значит чётким пониманием.
лёгкой модифицируемостью.
повторным использованием
и т.п.
---------------------------------------------------
появляется твой вопрос, что иногда это не нужно,
а фантики всё равно делают!
так вот делают не обязательно для внешнего результата,
ещё и для внутреннего удовлетворения, что как не странно приводит к повышению производительности.
Думаю от применения ООП не может быть вреда.
и сделать по оопшному это всегда, что то значит иной раз это может быть не осознано.
Программирование в этом плане приближается к искусству, программа к картине где всё гармонично. Польза от искусства и гармонии не оценима.
качество оно не только функциональное
совпадение результата со всеми требованиями.
Качество, также бывает эстетическим, со временем начинаешь чувствовать ООП стиль, который обязательно оборачивается:
хорошей структурой - значит чётким пониманием.
лёгкой модифицируемостью.
повторным использованием
и т.п.
---------------------------------------------------
появляется твой вопрос, что иногда это не нужно,
а фантики всё равно делают!
так вот делают не обязательно для внешнего результата,
ещё и для внутреннего удовлетворения, что как не странно приводит к повышению производительности.
Думаю от применения ООП не может быть вреда.
и сделать по оопшному это всегда, что то значит иной раз это может быть не осознано.
Программирование в этом плане приближается к искусству, программа к картине где всё гармонично. Польза от искусства и гармонии не оценима.
2006-11-24 @ 14:28
Ответ для agahov
Отказываться от хорошей структуры и лёгкой модифицируемости я не призываю. И более того считаю это губительным.
Я говорю о фанатичном стремлении к излишней гибкости, и стремления к возможному повторному использованию даже тогда, когда оно может реально никогда не пригодиться.
Все-таки на то и существует рефакторинг, чтобы в какой-то момент осознав, что что-то нужно использовать повторно, это выделить и использовать.
Отказываться от хорошей структуры и лёгкой модифицируемости я не призываю. И более того считаю это губительным.
Я говорю о фанатичном стремлении к излишней гибкости, и стремления к возможному повторному использованию даже тогда, когда оно может реально никогда не пригодиться.
Все-таки на то и существует рефакторинг, чтобы в какой-то момент осознав, что что-то нужно использовать повторно, это выделить и использовать.
2006-11-24 @ 14:46
Юля, не путай ООП и гибкость. Закладывать излишнюю гибкость и писать ООП-стильно - это разные вещи.
А мой пример ты не поняла. Если аристократ с утонченными манерами вдруг в один момент решит, что в этом случае они нецелесообразны, то он уже не аристократ. Как говорил знаток психологии Зигмунд Эн.: и сто крат не аристократ, а сто первый - как первых сто. Но это так, лирическое отступление, легкое увлечение психологией.
О чем это я? Забыл
А мой пример ты не поняла. Если аристократ с утонченными манерами вдруг в один момент решит, что в этом случае они нецелесообразны, то он уже не аристократ. Как говорил знаток психологии Зигмунд Эн.: и сто крат не аристократ, а сто первый - как первых сто. Но это так, лирическое отступление, легкое увлечение психологией.
О чем это я? Забыл
2006-11-24 @ 15:15
Ответ для Constantiner
Я стараюсь и не путать ООП и гибкость. И вообще говорила об _излишней_ гибкости и о фанатичном следованиям заповедям ООП.
И цитирую толковый словарь. Фанатизм - это доведенная до крайней степени приверженность к каким-либо верованиям или воззрениям, нетерпимость к любым др. взглядам.
Я стараюсь и не путать ООП и гибкость. И вообще говорила об _излишней_ гибкости и о фанатичном следованиям заповедям ООП.
И цитирую толковый словарь. Фанатизм - это доведенная до крайней степени приверженность к каким-либо верованиям или воззрениям, нетерпимость к любым др. взглядам.
2006-11-24 @ 15:23
Комментарий от: Евгений Н. [Посетитель]
Истина как всегда где-то по середине.
Есть best practics (по книгам от мировых гуру, и так) и
единая политика от лица ведущего программиста (Костя).
Есть возможность пробовать, и на пробах, т.е. на своем
собственном опыте - постигать что-то, понимать отчетливо -
все плюсы и минусы того или иного подхода (Юля).
Сочетание всего этого - и дает лучший результат, имно.
Есть best practics (по книгам от мировых гуру, и так) и
единая политика от лица ведущего программиста (Костя).
Есть возможность пробовать, и на пробах, т.е. на своем
собственном опыте - постигать что-то, понимать отчетливо -
все плюсы и минусы того или иного подхода (Юля).
Сочетание всего этого - и дает лучший результат, имно.
2006-11-24 @ 15:34
Рефакторин как раз не должен добавлять новой функциональности - по определению.
Он служит для улучшения структуры кода в целом. А хорошая структура позволяет сделать что то ещё.
т.е заниматься этим можно и даже нужно без видимой причины.
Как минимум это даст удовлетворение от проделанной работы и полученного результата.
Так реально не только то, что можно пощупать, твоя радость от хорошего кода очень даже ощутима...
Он служит для улучшения структуры кода в целом. А хорошая структура позволяет сделать что то ещё.
т.е заниматься этим можно и даже нужно без видимой причины.
Как минимум это даст удовлетворение от проделанной работы и полученного результата.
Так реально не только то, что можно пощупать, твоя радость от хорошего кода очень даже ощутима...
2006-11-24 @ 15:56
О, теперь я знаю, как зовут одного моего знакомого начинающего флексера :-)
Кстати, в Cairngorm именно так все и происходит в случае передачи событий от интерфейса через фронт контроллер -- командам; строго одно событие -- одна команда (поправьте, если я неправ). Этим достигается некоторая четкость структуры, однозначность что ли.
Например, когда есть только один-единственный слушатель и реально можно использовать просто переданный единственный объект Delegate для обработки события.
Кстати, в Cairngorm именно так все и происходит в случае передачи событий от интерфейса через фронт контроллер -- командам; строго одно событие -- одна команда (поправьте, если я неправ). Этим достигается некоторая четкость структуры, однозначность что ли.
2006-11-24 @ 16:16
Все хорошо в меру, главное поймать эту границу "хорошо/плохо"
Меня тут некоторые личности обзывают фанатегом %) И если следовать этим пунктам то из меня получается отличный фанатег. Это дает порой хорошые плюсы (? кто сказал плюсы) в больших проектах.
Просто очень приятно когда все сделано красиво со стороны кода и работает тоже красиво %). Я за японцев - делать нужно качественно даже когда этого не требуют.
Я тут недавно вывел свою теорию супер лени оправдывающую фанатизм:
Есть такая пословится, что ленивый все делает дважды. В програмщине она ох как права. Если поленится то часто приходится все переделывать(причем и не один раз). Поэтому лучше один раз хорошо все продумать и сделать с первого раза качественно чем потом 48 раз напрягаться. Ведь при хорошо продуманой архитектуре/проекте, в конечном результате работы получается меньше! А думать это вам не по клаве клацать. Думать можно и за пивом, и во сне...
Меня тут некоторые личности обзывают фанатегом %) И если следовать этим пунктам то из меня получается отличный фанатег. Это дает порой хорошые плюсы (? кто сказал плюсы) в больших проектах.
Просто очень приятно когда все сделано красиво со стороны кода и работает тоже красиво %). Я за японцев - делать нужно качественно даже когда этого не требуют.
Я тут недавно вывел свою теорию супер лени оправдывающую фанатизм:
Есть такая пословится, что ленивый все делает дважды. В програмщине она ох как права. Если поленится то часто приходится все переделывать(причем и не один раз). Поэтому лучше один раз хорошо все продумать и сделать с первого раза качественно чем потом 48 раз напрягаться. Ведь при хорошо продуманой архитектуре/проекте, в конечном результате работы получается меньше! А думать это вам не по клаве клацать. Думать можно и за пивом, и во сне...
2006-11-24 @ 16:46
Ответ для rost
А у меня похоже аж два таких знакомых флексера.
А по поводу вопроса о Cairngorm, то один из них точно должен знать. Надеюсь, что Костя заметит твой вопрос и ответит.
А у меня похоже аж два таких знакомых флексера. А по поводу вопроса о Cairngorm, то один из них точно должен знать.
Надеюсь, что Костя заметит твой вопрос и ответит.
2006-11-24 @ 17:10
Ответ для __i
Что касается больших проектов, то, согласна - там нужна большая доля фанатизма, причем ото всех участников. Большие проекты лучше делать по всем правилам. И тем более, когда работает команда, то так всем проще.
По-моему, Хемингуэй писал, что есть два типа писателей - одни, долго думают, в процессе обстоятельно и долго пишут, им практически не приходится ничего потом исправлять. Другие пишут быстро - им пришла мысль, они написали, еще одна мысль - опять написали, пишут быстро, но зато потом много правят. Видимо с программистами также.
Что касается больших проектов, то, согласна - там нужна большая доля фанатизма, причем ото всех участников. Большие проекты лучше делать по всем правилам. И тем более, когда работает команда, то так всем проще.
По-моему, Хемингуэй писал, что есть два типа писателей - одни, долго думают, в процессе обстоятельно и долго пишут, им практически не приходится ничего потом исправлять. Другие пишут быстро - им пришла мысль, они написали, еще одна мысль - опять написали, пишут быстро, но зато потом много правят. Видимо с программистами также.
2006-11-24 @ 18:05
Комментарий от: tracker [Посетитель]
Oхххх, девушка вы со мной не знакомы? я болен... Кто нибудь знает где лечат ООП Фанатиков?
2006-11-25 @ 17:43
Ответ для tracker
ООП фанатиков не надо лечить, вас надо оберегать как редкий вид.
ООП фанатиков не надо лечить, вас надо оберегать как редкий вид.
2006-11-27 @ 10:54
Здравствуйте,
Я становлюсь фанатиком (очень нравится). Решил переписать все исходники в оо-стиле. Столкнулся с проблемой: написал класс extend к movie clip, в нем есть метод resize, он вызывается на событие _root.onResize (stage слушает). Все работает как надо, только когда событие происходит, this относится уже к _root (а не к нужному объекту). Нет разницы, объект-listener или _root (все равно на рут). Пример:
Я делаю неправильно? А-а-а, пожалуйста, подскажите что! Жизненно необходимо получать размеры рабочей области (по-человечески, без интервалов), да еще и вызывать другие методы из resize. Как вернуться к объекту?
Я становлюсь фанатиком (очень нравится). Решил переписать все исходники в оо-стиле. Столкнулся с проблемой: написал класс extend к movie clip, в нем есть метод resize, он вызывается на событие _root.onResize (stage слушает). Все работает как надо, только когда событие происходит, this относится уже к _root (а не к нужному объекту). Нет разницы, объект-listener или _root (все равно на рут). Пример:
class x {
private var sW:Number;
private var sH:Number;
//---
function x() {
this.sW = 0;
this.sH = 0;
_root.onResize = this.resize;
Stage.addListener(_root);
}
//---
private function resize(Void):Void {
this.sW = Stage.width ;
this.sH = Stage.height;
}
Я делаю неправильно? А-а-а, пожалуйста, подскажите что! Жизненно необходимо получать размеры рабочей области (по-человечески, без интервалов), да еще и вызывать другие методы из resize. Как вернуться к объекту?
2006-11-28 @ 06:53
Ой, прошу прощения, туплю (понял, исправил, заработало).
var listener = this;
listener.onResize = this.resize;
Stage.addListener(listener);
var listener = this;
listener.onResize = this.resize;
Stage.addListener(listener);
2006-11-28 @ 10:04
Ответ для 7-й прохожий
Могу предложить еще вариант:
import mx.utils.Delegate;
var listener = new Object();
listener.onResize = Delegate.create(this, resize);
Stage.addListener(listener);
Могу предложить еще вариант:
import mx.utils.Delegate;
var listener = new Object();
listener.onResize = Delegate.create(this, resize);
Stage.addListener(listener);
2006-11-29 @ 15:33
Спасибо. Значит так будет правильнее, усвоил. Только вот, еще я фанат оптимизации и небольших размеров, а класс делегирования весит 480 байт – вес половины моего класса (с полным функционалом).
2006-11-29 @ 17:01
Ответ для 7-й прохожий
Ну если фанат небольших размеров, тогда вынужден будешь все сам писать, вместо того, чтобы пользоваться благами цивилизации.
Ну если фанат небольших размеров, тогда вынужден будешь все сам писать, вместо того, чтобы пользоваться благами цивилизации.
2006-11-29 @ 17:18
В том и есть кайфъ ))))
2006-11-29 @ 17:53
Bingo!
Разве что кроме седьмого пункта
Разве что кроме седьмого пункта
2007-02-16 @ 11:12
Bingo! Разве что кроме седьмого пункта
Ты - уникум. 8 из 9-ти.
2007-02-19 @ 11:31
RSS лента комментариев этой записиОставить комментарий
