Как разбить код AS3 на несколько as-файлов?

[BadaBooom]

Работаю в Adobe Flash Profesional CS5.5, не в кадрах, в классах. Создал проект в формате .fla, в .as-файле (Main.as) написал код AS3. Хочу разбить код на несколько as-файлов. Вопрос в том, как это сделать? Что должно остаться в файле Main.as, что следует переносить в другие as-файлы, а главное как обеспечить взаимодействие всех этих файлов так, чтобы код работал (хочу понять принцип, было бы здоров посмотреть примеры кода в разных as-файлах какого-нибудь простенького проекта)?

Только начал писать в классах, потому кое-что не понятно.

Заранее спасибо тем, кто не останется равнодушным и поучаствует в теме.

[in4core]

А не почитать ли на Колин Мук AS3 ? :)

[alexcon314]

Класс - логическая единица, кирпичик приложения, условно говоря.
Работа программы, написанной на классах, сводится к созданию экземпляров нужных классов.
Вы уже используете классы, например MovieClip, Sprite, Graphics, поэтому, думается, представляете о чем идет речь.
Компилятор AS требует описания каждого класса в отдельном текстовом файле. Поэтому разбить код на несколько файлов означает разбить код на классы. Т.е. нужно вычленить эти самые кирпичики из общей логики приложения. Зачастую кирпичиками являются клссы-наследники Sprite, несущие роль отображения графических элементов приложения.
Файлы классов в самом тривиальном случае можно держать все в одной папке. По мере разрастания приложения их можно группировать в пакеты, т.е. физически это означает их можно разложить в структуре директорий, названия которых будут повторять названия пакетов.

[Fogflasher]

Присодеиняюсь к вопросу. Справедливо ли утверждение:
Любой достаточно крупный единый Main.as класс можно разбить на несколько классов, согласно некоторому паттерну программирования.
(То есть всегда найдется какой-либо паттерн).

А значит, вместо того чтобы парицца над тем, как нужно разбивать класс...
Мы просто слепо расчленяем его на блоки некоторого паттерна и хихикая потираем паучьи лапки.

[FlashRus]

А значит, вместо того чтобы парицца над тем, как нужно разбивать класс...
Мы просто слепо расчленяем его на блоки некоторого паттерна и хихикая потираем паучьи лапки.

Достаточно странное утверждение.
Преждем чем пользоваться каким-либо паттерном, надо понимать как он работает, а не слепо следовать его идеологии.

[Psycho Tiger]

А я бы рад, если бы была директива #include. Это был бы почти mixin. Зажили бы.

[caseyryan]

Так ведь она есть, только без решетки.

Как по мне, это нелепо для ас3

Любой достаточно крупный единый Main.as класс можно разбить на несколько классов, согласно некоторому паттерну программирования.
Чье это утверждение?
Я скажу так, новички почти никогда не понимают как правильно пользоваться классами, особенно если флеш - это их первый опыт программирования. Понимание придет со временем, главное практиковаться, читать побольше чужих (грамотных) кодов, не пренебрегать справкой, и все получится. Если постоянно что-то писать в классах, читать умные книжки, то через некоторое время понимание будет достаточным, чтобы подобные вопросы вообще не приходили в голову. Не нужно питать иллюзий о том, что кто-то сейчас придет и скажет такую умную фразу, после которой всё сразу, магическим образом, станет понятно. Все через это проходят, кто решил заниматься программированием. Всем, кто еще не понял что такое классы и как с ними работать, рекомендую прислушаться к совету in4core и почитать Колина Мука. Русский вариант называется Колин Мук - Actionscript 3 для флеш. Оригинал Colin Moock - Essential ActionScript 3

[Fogflasher]

У Мука нет конкретно про разбиение кода на классы, насколько я помню.
Многоклассовые примеры конешно есть, но вот так чтобы: "Ребята, вот был такой-то Main, а сейчас мы разобьем его на кучу классов", такого нет.

И Феронато в своей книжке про игры пишет всё в одном большом Main. Ну иногда юзает классы мувиклипов с небольшими кодами.

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

А то, что все приходит с опытом постоянного программирования, оно понятно конешно.

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

Мне вот недавно удалось разбить один такой "болотный" Main на классы, но не до конца : )
И некоторые вещи я не понимаю как перенести в отдельный класс. Отсюда возникают идеи, злоупотреблять статическими классами например. Понаделать статиков, которым из некоторого небольшого ядра передавать объекты, массивы, и всё что угодно.

[alexandrratush]

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

То что вы называете "разбить код AS3 на несколько as-файлов" это и есть ООП. Если ООП непонятно, то паттерны уж тем более.

У Мука нет конкретно про разбиение кода на классы, насколько я помню.
Как нету? А глава посвящена ООП это не оно?

[Akopalipsis]

У Мука нет конкретно про разбиение кода на классы, насколько я помню.
На сколько я помню - есть и даже очень подробно, при создании нового свойства много комментариев и обьяснений о том, как лучше распределить по классам.
И Феронато в своей книжке про игры пишет всё в одном большом Main.
Даже глупый я понимаю, что такое читать вредно.
что новичок с одной стороны еще не дорос до паттернов
О них нужно читать в самом начале и не делать каких то непонятных приложений, которые как раз и калечат сознание.
И на самом деле всё очень просто... тут я хотел сказать как учил я, но не хочу чтобы Вам ещё раз показалось, что мои фразы напичканы - "змеиной лестью", "самобичеванием" и прочим... И хочется надеяться, что Вы один из немногих, который верен своим словам и не станет
как и я задавать много вопросов, а всё постигнет самостоятельно и гордо..

[caseyryan]

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

[Fogflasher]

Как нету? А глава посвящена ООП это не оно?
Номер главы, если вас не затруднит.

при создании нового свойства много комментариев и обьяснений о том
Ссылку на страницу, пожалуйста.

Даже глупый я понимаю
Ох, опять этот коккетливый мазохизм.
Мы же знаем, что это далеко не так.

что такое читать вредно
Можно вот здесь поподробнее, в чем именно вредность.
И чем так омерзителен Феронато?

каких то непонятных приложений, которые как раз и калечат сознание.
Это какое например? Можно конкретное предложение указать.

И на самом деле всё очень просто... тут я хотел сказать как учил я, но не хочу чтобы Вам ещё раз показалось, что мои фразы напичканы - "змеиной лестью", "самобичеванием" и прочим...
Хороший пример "не калечащего сознания читателя" предолжения.
Лично вас я никогда и не упрекал в задавании множества вопросов, кстати говоря.

[alexandrratush]

Номер главы, если вас не затруднит.
Номер не помню, а название - "Наследование", еще есть описание статических методов и все остальное, что знать нужно как дважды два.

[Akopalipsis]

Не понимая классы, не надо кидаться в паттерны.
Не понимая, конечно! Но не нужно же что то делать, для того, чтобы познать их работу.
Разобраться в классах, мне помогли события. я когда книги читал, то сразу понял, что события это что то важное. Начал просто в пустых классах тренироваться, не получалось, а когда понял, как передавать события, то и в классах разобрался. И настал момент, когда я немного потратил время зря, пока мне не посоветовали почитать о шаблонах.
Ссылку на страницу, пожалуйста.
36-836
И чем так омерзителен Феронато?
я его не читал, но если верить Вашим словам, то в книге все приложение пишется в классе Main, это же не нормально.

[Fogflasher]

Номер не помню, а название - "Наследование", еще есть описание статических методов и все остальное, что знать нужно как дважды два.

Да это вобщем понятно. Но согласитесь, что разбить на классы можно также и не одним способом. Наверняка может быть разная логика: "объект = класс", "процесс = класс", "класс - это комплекс объектов" или еще как-то. Опять же, разбить можно на 3 класса, а можно, наверное, на 15.
Где критерий количества частей, например.

36-836
Ссылка на всю книжку - очень мило. Правда, не ясно, почему 836, а не 911.

я его не читал, но если верить Вашим словам, то в книге все приложение пишется в классе Main, это же не нормально.

Вот кстати тоже весьма интересный филосовский вопрос: а почему ненормально?
Если критерий: работоспособность приложения, то там всё ок.

Хотите глупых вопросов, пожалуйста:
Зачем вообще на классы всё разбивать? Чтобы было понятно другим, если ты работаешь в команде? Чтобы потом самому легче было разобрать? Чтобы логика приложения была более ясной? Потому что так проще работать?

[FlashRus]

а почему ненормально?
В пределах некого хеллоуворлда - вполне нормально.

Если критерий: работоспособность приложения, то там всё ок.
Работоспобность программы резко снизиться при острой необходимости внести изменения и реализовать расширение функционала.
Ясно дело что машине вообще плевать что она делает и для неё любой код, любая ошибка и т.п. является номральным явлением. Если Вы занимаетесь разработкой проекта хотя-бы среднего уровня сложности используя метод "пишется в классе Main", то вы либо недопишите приложение, либо как-раз таки посрадает его работоспособноть и стабильность в связи с запутанностью и отсутствием структурирования.
А если понадобиться внести изменения, то - перписывать с нуля.

Добавлено через 2 минуты
И ещё...
Грамотное проектирование и структурирование на ранней стадии, да даже что там говорить, любое проективрование на ранней стадии разработки позволит хоть как-то снизить риск возникновения неожиданных багов и увеличить шансы на дальнейшее расширение проекта.

[caseyryan]

И чем так омерзителен Феронато?
Своим стилем написания кода. Любит он писать "полотенца". Лично мне вообще не нравится как он пишет. В таких кодах очень сложно разбираться, тем более новичку.

[in4core]

Внесу свою лепту, может быть и глупую. Давай те говорить открыто : кто нибудь из вас сможет сказать АДЕКВАТНО, почему писать код в одном классе плохо? Думаю нет, ибо нет такого понятия. Я сам конечно же как и все более менее адекватные товарищи данного форума не пишу код в одном мейнике, НО.. да да да, очень большое НО... Почему мы так не пишем? Кто то потому лишь - что ВСЕ говорят, что так делать плохо, кто то потому, что познал жизнь работы в коллективе, кто то просто сам дошел до этого. Писать код в ОДНОМ классе или в нескольких - не влияет на расширяемость никак - как сказал FogFlasher - ну а тем более не влияет на скорость работы.
Давай те задумаемся все таки над этим вопросом более серьезно, хотя многим кажется это смешно.
1) Почему не влияет на расширяемость : да потому, что в одном файле я ВИЖУ все, я вижу связи сразу(gotoDeclaration), я вижу куда что ведет, пускай хоть и 1000+ строк, но я это вижу очень просто, нежели чем в в 10 классах по 100 строк. Знаете, тут можно спорить часами, все равно никто прав не будет, почему? да потому, что нет такой же четкой позиции, что например - 31 декабря призананный новый год... да и тут тоже можно спорить)))) смешно да...
2) Поговорим про удобство и вариант работы команды. Тут вот есть занозы - какие, спросите вы. У нас есть большое приложение - допустим какая то игра, где работают, по меньшей мере 2 флешера. Один пишет логику ( клиентскую соответственно ) , другой допустим программирует интерфейс. Они одноверменно не могут писать в одном классе - это логично, приходится разбивать на части и т.п. ...
....
...
и вот думая об этом, потихоньку, даже работая одному, ты понимаешь, что разбивка на части дает тебе приимущество - написал часть и забыл, приступил к другой, забыл, к третьей. И тут уже идет разговор не про разделение программы на части, а про этапы работы скорее.

P.s. - да пишите вы где хотите - работая одному, можно писать такую ересь , что мама не горюй! Но не забывайте, что если вы программист , и хотите продолжить свою карьеру, то в будущем, возможно - вы будете работать не один , и тогда вам придется познать классовость , разбивку и сторожки типа ГитХаба )))
Всем добра!
Пьяный, вечер)))

[caseyryan]

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

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

[Psycho Tiger]

Главное чтобы код был DRY. В одном классе, если его можно разбить на два и более по принципам ООП это всегда значит что он не драеный.

[Котяра]

Мартин Фаулер. Рефакторинг.
Толстенная книга про то как, зачем, когда и каким образом рефакторить.

[alexcon314]

Разбиение кода на файлы-модули-классы немало способствует увеличению скорости компиляции, внезапно.
Стремление держать код в одном файле ну никак нельзя расценивать, как разумное стремление.

[in4core]

caseyryan нет нет, я не хотел сказать прямо, что не влияет ни на расширяемость ни на качество и т.п., я просто порассуждал в своем ключе на самом деле. Естественно ни ты ни я так не пишем.