![]() |
Правильная реализация эффектов для мыши
Давненько я не делал всякие эффекты. Тогда я еще маловато знал об as3 и усердно зачитывал Мука. Итак, с утра что-то стукнуло в голову, дай-ка, думаю, пока выходной, понаделаю шаблончиков - авось когда пригодятся. Сделалось вот такое:
Код AS3:
|
Да в основном по мелочи вроде...
speedRotation и alphaDown лучше сделать константами - их значения все равно не меняются. Код AS3:
|
Где-то тут на форуме видел, что константы после компиляции становятся переменными. Вообще, хотелось бы потом сделать полные настройки. То есть, в конструктор передаем Object:
Код AS3:
|
Код AS3:
Цитата:
|
Порядок важен, Тигер. А все случаи не предусмотришь. Нужно мне в твоем коде вместо hello написать hell. И придется перед этим писать все другие параметры тоже, переписывая их дефолтные значения.
А с обджектом хоть местами меняй, хоть какое значение задавай. Я свой фреймворк сейчас на обджекты перевожу - удобно, на мой взгляд. |
Обджекты - ущерб автокомплиту. Я считаю что обджекты следует использовать только для передачи ключ=>значение, когда число и имена ключей заранее неизвестны. Как яркий пример - твинеры.
|
Цитата:
Цитата:
Код AS3:
Так вот, здесь нужно только заглянуть в класс, где заботливой рукой я указал все возможные параметры, в коструктор передавать объект с этими параметрами. Ты же это и имел в виду? Больше ни для чего обджекты я не использую из-за той же типизации и того же автокомплита. |
КорДум, а зачем такая колбаса, если можно передать готовый, уже настроенный DisplayObject?
|
TanaTiX, в смысле? Класс в примере с обджектом - это создание прямоугольного фона нужной ширины/высоты/прозрачности/итд. Если не указываешь обджект в конструкторе - берутся дефолтные значения, уже заданные в классе.
|
Зачем его создавать в том классе? Проще передать готовый. И вся надобность в Object-ах отпадет. Передали DisplayObject, пересохранили ссылку на объект и делаем что хотим. Если нет DisplayObject-а в параметре - тогда создаем некую форму, определенную по умолчанию, но ей не нужно передавать хренову тучу значений, т.к. все параметры определены внутри класса. Или имеется в виду определить все параметры внутри функции на тот случай, если DisplayObject отсутствует, чтоб не плодить лишние свойства, и их передать параметром для функции, которая запустится опять же только в том случае, если не определен DisplayObject? Но даже в таком случае, т.к. это закрытая функция, нет ИМХО особой надобности создавать Object.
Или я что-то не так понял? |
TanaTiX, либо вы не поняли меня, либо я вас. По какому принципу работают твинеры?
Код AS3:
Вот полный код, надеюсь, меня не покарают за такие большие листинги: Код AS3:
|
Символом $ отмечаются финализированные методы по конвенции. Для приватов существует "_".
В твинерах мы не знаем что будем менять. x,y, vasya или petya. В твоём случае было бы логичней вообще конструктор оставить пустым, а width/height и ко сделать сеттерами. |
Я имею в виду следующее:
Вот сейчас мы хотим создавать прямоугольник, завтра круг, а послезавтра улыбающуюся девочку. И если с кругом и прямоугольником все относительно просто, то вариантов настройки девочки гораздо больше - запаримся все описывать. Вот я и предлагаю в BgSimple передавать не Object, а DisplayObject, уже настроеный как хотим. В результате избавляемся от передачи тучи параметров и их переопределения+гибкость во внешнем отображении. Сравнение с твином ИМХО не очень удачное - там другие задачи, там все параметры у объектов уже есть, а в этом случае все создается нами. |
Цитата:
Цитата:
Цитата:
|
Цитата:
|
TanaTiX, класс BgSimple создает только прямоугольники. Он не подразумевает создание 3Д-фона, меняющегося по времени. Все параметры по умолчанию есть. Хочешь - меняй. Не хочешь - не меняй. Или меняй только ширину-высоту. Конечно, если мы делаем, скажем, скроллбар, в него пихаем уже ДисплейОбджекты, уже настроенные визуально. В таком классе реализуется только сборка воедино, позиционирование и функционал.
Если мы будем передавать уже настроенный обджект в класс создания фона, необходимость в классе пропадет, ибо дисплей обджект уже настроен, как надо, разве нет? Добавлено через 1 минуту Psycho Tiger, класс фона статичный, он не требует, чтобы его в рантайме переделывали. Так зачем делать сеттеры, если можно сразу указать в конструкторе все, что нужно? Цитата:
|
Тогда я перестаю понимать связь кода в 1м сообщении и в 11м.
|
Чтобы не отходить от темы, переложим нашу дискуссию на эффект со звездами. Тут я уже сомневаюсь. Наверно придется сеттерами делать. Ибо вдруг я захочу через пару секунд звездочки заменить летающими девочками? А тут раз, переопределил - и все, звездочки отживают свое, на их место встают бомбардировщики ИЛ-Девочка-2. А потом бац! - я захотел ускорить их сорость или проредить их толпу. И тут сеттером я изменяю все это. Это да, тут сеттеры хороши.
Но в случае с фоном, имхо, удобнее написать Код AS3:
Добавлено через 2 минуты TanaTiX, это мы так тихонечко подошли к гибкости настройки. |
Цитата:
|
Так, еще, логика эффекта не была совсем правильной. Сейчас подобраны такие параметры, что все смотрится очень даже плавно. Но стоит только сменить шаг прозрачности на меньший - хвост создается вспышками, как бы облаками. Сделал по таймеру создание кусочка хвоста.
Хочется при создании каждой звездочки определять начальные значения скорости и шага поворота. Как это лучше сделать? Конечно, можно создать класс одной звезды, определить у нее публичные свойства. Но как-то не хочется создавать еще один класс. |
Цитата:
К тому же, ни один параметр не является обязательным - как раз случай Кордума. И если думать что г-да Адоубовцы пользовались каким-то другим образом мышления, отличного от моего - то один фиг не Object в конструкторе. |
Тигер, вот сижу я сейчас над классом фона и думаю: а если сделать и необязательную передачу обджекта в конструктор, и сеттеры? Что-то насчет ненужности изменений я погорячился, а если и правда, нужно будет в определенный момент времени сменить цвет бордюра или фона?
Но вот смотри, два варианта. Первый: мы не делаем обджект в конструкторе, делаем только сеттеры. Плюсы - меньше кода в классе. Минусы - больше строчек в коде применения класса. Второй: мы делаем и то, и то. Плюсы и минусы в таком случае меняются местами. Что посоветуешь? |
Я бы самое важное вынес в конструктор. Конструктор бы дёргал сеттеры. Опциональное - оставил только на сеттерах.
Тут смотри как тебе удобнее. Однозначно против хэшей в таких случаях я из за того что мне нужно помнить, как же зовутся параметры (спорно - подсказки к коду, но не всегда удобно искать глазами, как я назвал метод - destruct, destroy, clear или clean, по автокомплиту искать проще), не ошибиться при их вводе (а опечатка эта может проявится не сразу - не факт, что код выполнится, а значит, не факт что опечатка всплывет), не ошибится с их типом (принимаю только интовые, а захотел половину - и не могу понять, в чем дело - не вижу тип). |
Цитата:
|
Цитата:
Код AS3:
|
Цитата:
Вообще редкий класс задаёт всё что только может в конструкторе. Если задаёт - на то есть причины. @Кордум, ага. Часто встречаю что люди в сеттерах и в конструкторе код копипастят фактически. Сказал на всякий ) |
Тигер, неудобство такого подхода в том, что приходится придумывать вменяемые имена сеттерам, ибо, допустим, width уже используется. Писать, что ли
Код AS3:
|
Ну width можно переопределить, я очень сомневаюсь что доступ к оригинальному width DisplayObject`а нужен в подобного рода эффектах. А если нужен - делай сеттер effectWidth
|
Цитата:
|
В таких эффектах - да. Я спрашивал на будущее. Хорошо, с передачей параметров/настройкой разобрался. Есть еще что-то, что можно в целях оптимизации/исключения быдлокодности сделать? Опираемся на код первого поста, с поправкой, что там поселился таймер создания звездочек.
Добавлено через 50 минут Повторюсь маленько: Хочется при создании каждой звездочки определять начальные значения скорости и шага поворота. Как это лучше сделать? Конечно, можно создать класс одной звезды, определить у нее публичные свойства. Но как-то не хочется создавать еще один класс. |
Цитата:
|
Bgg, сейчас Тигер скажет, что это не трушно ;)
Я тоже не вижу смысла делать сеттер с простым переназначением переменной. Не вижу смысла - и не делаю. Но здесь есть некоторый плюс. Скажем, у нас есть класс, внутри таймер. Нужно поменять задержку таймера. При простом свойстве нжно писать obj.timer.delay, а с геттером-сеттером можно сделать просто: obj.timerDelay |
Цитата:
|
Цитата:
Чтобы сделать это менее бажным, нужно как минимум добавлять везде дополнительный метод checkArguments(obj), который будет проверять валидность всех имён аргументов и их типов. |
Цитата:
Так или иначе, не стоит смотреть сверху вниз или говорить о какой-то бюрократии. Тебя я очень уважаю как человека и разработчика, однако мы не законы природы постулируем. Есть разные мнения, есть разные подходы, а быть нонконформистом с самоцелью мне кажется глупым. Если считаешь, что мои рассуждения в чем то неправильны, что не стоит так делать по каким то причинам (например, свои мысли о хэшах я привёл) - поделись. Если считаешь, что этот подход просто "не мужской" - расскажи, как по мужски. Может я по другому не умею. Цитата:
Цитата:
|
Цитата:
|
Где-то и как-то читал про ступени в развитии программиста. Точно все не помню, поэтому расскажу своими словами. На первой ступени, он ничего не знает, тупо копирует чужой код не понимая смысла в его действии. На второй ступени, пытается использовать все методы сразу, чисто лишь потому, что он их знает. На третей ступени, перечитаны тонны литературы, пишутся сотни строк кода, чтобы соответствовать стандартам. На четвертой ступени, программист познает истину и начинает просто программировать.
Программировать нужно исходя из задачи, поэтому не важно, сколько будет аргументов в конструкторе. Важно, чтобы они ставились туда осознано. |
Раз пошел уже оффтоп... iNils, ты про эту забавную, но жизненную статейку?
И вот еще нечто похожее, ради прикола можно узнать себя где то. |
Типа того.
|
Цитата:
|
| Часовой пояс GMT +4, время: 22:44. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.