Форум Flasher.ru - Кто как разрабатывает Flex приложения.

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- Флейм (http://www.flasher.ru/forum/forumdisplay.php?f=53)

- - Кто как разрабатывает Flex приложения. (http://www.flasher.ru/forum/showthread.php?t=101496)

Кто как разрабатывает Flex приложения.

Вот интересно мне опрос провести (среди тех кто уже имел опыт работы с flex) что представляют ваши проекты:
1-весь код в одном mxml
2-множество mxml c логикой, а также свои сообственные mxml компоненты
3-весь графический интерфейс в mxml, а логика в отдельных AS классах
4-полностью AS3 проект с использованием flexовского фреймворка
5-через ( )о( )

Ну...так как я тут самый крутой флекс разработчик на форуме.
Я и отвечу.

Флекс проект это вообще огромная бандура, это тысячи классов (Flex Framework + еще пара фреймворкров/библиотек + свои адапотры и компоненты) И поэтому получается все пять пунтков

И компоненты в одном мхмле, и мхмле только GUI а логика разделена между AS и MXML (некоторую логику легче записать через bindings но злоупотреблять ими не стоит) и конечноже через жопу случается. Так же постояно идет наем аутсорсеров из индии которые наворотят кода, и туда заглядывать страшно (работает да и ладно).

Я не считаю, что так его разрабатывать нужно, но мы живем не в идеальном мире =)

MXML компоненты с логикой+AS-расширения стандартных компонентов, обычно с целью нормализации поведения последних+набор своих классов...вобщем как сложится:)

согласен с Ниртом.
один чувак как-то сказал - думать надо не паттернами, а задачами.

Ну я хоть и сам начинающий флексер, но 3 последних способа уже попробовал, и вижу что никто не скажет как правильно разрабатывать Flex приложения

Лучше стараться разделять интерфейс и сложную логику по полочкам )

Mxml заставляем отвечать за дизайн, сложную логику разсовываем по AS-классам.

Простецкие задачи возлагаем на мхмл.

Иногда проще наколбасить mxml компонентик сам в себе. Например айтем рендер.

А еще бывает весело когда инвестор приезжает завтра, а нифига нету и надо за ночь сделать прототип=)

А потом влом писать по человечески, на этом прототипе и делают.

А потом ко мне обращаются и говорят - Давид, все нахрен летит, спасай, вот на таких дядек и надо работать =)

Мелкие проектики можно делать любым способом.
Но для разработки серьезных вещей, как минимум, надо:
- продумывать структуру компонентов
- реализовывать все необходимые интерфейсы
- реализовывать все необходимые абстрактные классы
- реализовывать все необходимые классы
- часто собирать и ОБЯЗАТЕЛЬНО пропускать через модульное тестирование критичные вещи

НО!:
без фанатизма!
если проектик мелкий и разрабатываемые компоненты больше нигде применять не надо будет - то можно и на скорую руку :)

Цитата:

Сообщение от Nirth

Ну...так как я тут самый крутой флекс разработчик на форуме.
Я и отвечу.

Вот это еще очень порадовало :)
Продолжаем в том же духе :):):)

Цитата:

Сообщение от librio

- реализовывать все необходимые интерфейсы
- реализовывать все необходимые абстрактные классы

...но соблюдая при этом осторожность и не теряя здравого смысла...у Джоэла Спольски есть хороший термин на этот счет: Architecture Astronaut(http://www.joelonsoftware.com/articl...000000018.html) - вот до этого доходить нельзя:)

Имхо главное это понятные названия придумывать. Не стесняюсь составлять из 3х 4х слов.

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

Я обычно стараюсь делать понятными переменные классов (всегда употребляю их с this...), если переменная у меня встречается в куче классов-чилдренов, то я ставлю перед ней _..., если в методе куча фармул, то я сокращаю имена переменных ,предварительно написав перед методом коммент. Это мой стиль программирования, я его никому не навязываю.

Цитата:

Сообщение от vapes

Обратили внимание, сколько "если" в вашем стиле? Употреблять this не советую - просто лишние буквы, у тому же вы заколебетесь делать рефакоринг Замена метода объектом метода (Replace Method with Method object) при таком подходе. Раз уж ставите подчеркивания в полях класса, то ставьте их везде, без исключений. И вообще в таких делах лучше не придумывать свой стиль, а ориентироваться на соглашения разработчиков крупных фреймворков типа
Java (походит для AS):
http://java.sun.com/docs/codeconv/ht...nvTOC.doc.html

или .NET (для AS не подходит, но посмотреть стоит):
http://msdn.microsoft.com/library/ru...guidelines.asp

Coding conventions для AS 3 от Adobe я не встречал, а те что для AS 2, морально устарели.

Насчет this не согласен.

this в классах не юзаю.

this в классах стараюсь не юзаю, но как тут this не использовать?

Код:

for (i = 0; i < comLenght; i++) {

        this['new' + i] = new Object ();

        hit = this['new' + i];

}

так я тоже не делаю=)

а как же тогда??
подскажи, если не тяжело =)

в класс прописывать свойства так..ну я не люблю.

если надо то создается объект(обычно это даже не Object а Dictionary если говорим о АС3, они меньше жрут ресурсов, более гибки в плане ссылок)

Код:

var dict:Dictionary = new Dictionary(true);



for(var i:uint = 0; i < 10; i ++)

{

dict[i] = i*2+3/4-5;

}

а если в АС2?

я кстати еще this юзаю в Delegate.create(this, func);

прими мои собалезнования=)

Естестественно, this надо использовать там, где без него не обойтись (например, если параметер метода совпадает с именм поля, или вы передаете его в качестве аргумента), но в остальных местах он просто лишний. Это у некоторых привычка от старых protоtype based версий ActionScript. Не спроста ведь в новых версиях сделали возможным его опускать? Вообще существует несколько основных разновидностей именования приватных полей класса.

Без подчеркивания: myField
Этот вариант имеет две проблемы: имя поля может быть перекрыто локальной переменной или параметром, нельзя определить геттер и сеттер с тем же именем. Последнее особенно актуально, с учетом того, что методы в ActonScript однозначно прнято именовать со строчной буквы. Можно, конечно не использовать геттеры сеттеры по мере возможности, но мы же взрослые дяди, и понимаем, что в коде на несколько десятков тысяч строк оставлять публично трочащие наружу поля чревато тяжелыми телесными повреждениями.

С подчеркиванием: _myField
Способ всем хорош за исключением эстетического плана. Лишнее подчеркивание анноит.

C++ стиль: m_myField
Анологичен предыдущему только еще непригляднее - здесь уже два лишних символа. Используется исключительно old school программистами, и теми, кто пытается им подражать, ибо никаких преимуществ по сравнению с вариантом с подчеркиванием у него нет.

Pascal стиль: fmyField
К счастью, ActionScript регистрочуствительный язык в отличие от Паскаля, поэтому здесь так извращаться не приходится.

this спереди: this.myField
С этим вариантом есть проблемы того плана, что если вы захотите вынести метод класса, например, в функцию или сделать метод статическим, то придется удалять все this. Если при этом внутри метода будут объявлены переменные с тем же именем, что и имя поля, то придется переименовывать поля. Кроме того, за пределами AsctionScript этот способ крайне редок.

С большой буквы: MyField
За такое надо убивать из рогатки.

Очевидно, что единствеенный кошерный варинат, который позволяеет везде и без исключений применять единоообразную технику именования полей - вариант с пдчеркиванием. В C# можно было бы избрать первый вариант, ибо в .NET принято именовать методы с прописной буквы, в Java так же, потому что там пока еще нет свойств вообще. А вот в Pascal или Basic нельзя - реистронечуствительные языки. В ActionScript первому способу мешает наличие геттеров сеттеров.

Как говориться, мементо портабилити.

Да ладно, this убрать при переносе в static вообще не проблема, не надо делать из мухи слона. К тому же, в 99% случаев одной заменой this не обойдется, это будет едва ли не самая простая операция. Код и так и так править.

Цитата:

Сообщение от Entropy

... this надо использовать там, где без него не обойтись (например, если параметер метода совпадает с именм поля, или вы передаете его в качестве аргумента)...

Вот поэтому и использую его при обращении ко всем полям и методам класса. Либо всегда использовать, либо никогда не использовать.

this сразу дает понять и мне и компилятору, что обращение идет не к статическому полю и не к локальной переменной.

Правда, в нескольких проектах в блоге this отсутствует, каюсь

AS2 и его хелп все время приучал нас писать вещи типа mcBall вместо ball, arrBalls вместо Balls и так далее, чтобы не забыть что есть что. С this таже песня, потому как иногда без этого злосчастного this проект просто не хотел компилироваться (мелкие проги не в счет).

Всем новичкам очень рекомендую писать this, чтобы понимать логику и увеличивать читабельность и понимание своего кода.

конструкция this никак не увеличивает читабельность кода.

В статик методах лучше всего писать так: НазваниеКласса.имяСвойства.
Приватные свойства начинать с двойного подчёркивания: __свойство.
На тему названия методов с прописной буквы в АС, чесно говоря в первый раз слышу чтобы была такая договорёность или правило, геттеры и сеттеры — желательно но не обязаловка.

this пишу в основном в классах наследуемых от мувиклипа.

Да и объекты в цикле не создаю :). Разве что при обращении к мувиклипам или текстовым полям в цикле приходится использовать.

Код:



for (i = 0; i < xml.length; i++){

      this['text' + i + '_txt'].text = xml.childNodes[i].attributes._name;

}

__i и не ухудшает :)
Всего лишь дает понять, что то, к чему мы обратились, лежит где-то в классе (и к этому можно перейти по ctrl), а не объявлено внутри функции 150 строчек назад.

Всех кто использует this - казнить, а тех кто не использует - повесить.

предложите еще $ использовать вместо всего этого :~)
сразу код дорого смотреться будет: var $myMc :~)

Цену за работу будешь назначать по количеству значка доллара? :)

я могу понять когда this используют в таком коде

Код:

private var width:int;

private var height:int;



public function setSomethingAndInit(width:int, height:int):void

{

    this.width = width;

    this.height = width;

    redraw();

}

Но просто так пихать...для меня это сложней читать. Вобщем дело привычки, но я бы не нанял человека у которого this стоит там где не нужно=)

Nirth, ты обрушил все мои надежды :))

__etc если мне трудно читать код подчиненого, зачем мне такой подчиненый=)?

Возможно есть чувак которому трудно читать код без this, но если честно таких как я большинство, ибо в C#, Java this тоже не ставят пока не припечет.

Да и в Python (там вместо this – self) тоже не ставят.

Я ставлю, потому что FlashDevelop сразу мне предлагает выбор, что поставить, а потом стираю, потому что this меня бесит.

Цитата:

Сообщение от Kikasso

А ctrl + space жать не пробывал?:)

наверное многие знают, есть книженция "Горький вкус Java" Брюса Тейта. Там описываются проблемы красоты и единообразия кода, правда на Java, но для ас тоже полезно будет.

Цитата:

Сообщение от Nirth

__etc если мне трудно читать код подчиненого, зачем мне такой подчиненый=)?

Что бы подчиняться =))