В каких случаях стоит переходить на ООП? (ООП - и тигры у ног моих сели...)
 

Не могут ли люди, имеющие опыт грамотного применения объектно-ориентированного программирования, озвучить пару мыслей? :)
Я ни в коем случае не хочу оспаривать достоинства ООП и отстаивать обычное процедурное, но в каких приложениях стоит и в каких нет?

И как безболезненнее переходить на ООП? Литературы по этому вопросу написано немало, но авторы обычно очень косноязычны. (Увы, программисты - не гуманитарии ни разу. :confused: )

Вот, к примеру, у меня приложение - "шедевр" процедурного программирования. Несколько сотен функций, тысячи строчек кода, и не я начинал его писать...
Очень хотелось бы его причесать, заООПить, :rolleyes: ,чтобы было проще потом вносить изменения, но это все равно что заново с нуля переписать.
Гм. Если без лирики, то вопрос:
1) Нет ли случайно утилит, которые создают карту-схему зависимости всех функций в указанном AS или чего-то подобного (то есть какое-то подспорье "переписывающему большой скрипт с нуля")?
2) Нет ли все же приличной литературы по ООП, где, к примеру, применяется простой прием "вот как бы мы это написали процедурно" - "а вот как мы это напишем ООП-но"?

Я не уверен, что эта тема должна быть в этом разделе. Если какой-то раздел подходит больше, прошу переместить туда и сильно ногами не пинать. :)

По 2ому вопросу - посмотрите литературу по рефакторингу Java, начиная с того же Фаулера, очень поможет.

Из собственного опыта:
1) если внесения большого количества фич не планируется, лучше написать комменты по максимуму и успокоиться, т к ООПить нет смысла.
2) если нужно будет в будущем изменять, алгоритм такой:
- если есть код в on, onClipEvent - свести все на кадры
- свести код с кадров в один
- удалить устарвевшие конструкции
- удалить явное дублирование
- написать короткие комменты к большинству функций
- посмотреть, что можно заменить функциями из стандартных библиотек, заменить
- заменить свалку из функций на группу классов с набором статических методов

После этого смотрим, сколько осталось нераспиханного кода. Если мало, то можно рефакторить полученные классы (ну по сути, это псевдоклассы, от ООП далекие)

если говорить о книгах про AS, то мне нравится книга К. Мука "Основы АС2.0"

утилиты... ну, наверное Rational Rose ;) или ее более простые аналоги

ActionScript изначально прототипный ООП язык, как вы собираетесь переходить с ООП на ООП ?!

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

можно

аргументируйте

Советую автору и всем желающим почитать некоторые статьи вот тут: Парадигмы программирования.

Там можно почитать чем отличается функциональное программирование от объектно-ориентированного . И чем они хуже или лучше прототипного программирования. Эти парадигмы программирования в основном используются в AS 2/3.

Скажу основываясь на своем опыте если кода > 400 строчек лучше использвать классы, интерфейсы, абстракции, синглетоны и т.д. Если меньше писать как будет удобней (и быстрее).

Всё не находил повада поделится, но вот кажется оно. По материалам википедии один из противников ООП парадигмы, в частности Александр Степанов с ноября 2002 работает в компании Adobe, где занимается в основном преподаванием программирования. :)

т.е. этим вы хотите сказать, что 2000 функций запиханых в один фрейм, без насладования и других преимуществ ООП лучше, чем упорядоченный набор классов, в коде которых легко разобраться программисту, который видит код первый раз?
Да даже сам разработчик, написав такое через полгода будет копаться в своих скриптах с целью хоть как-то вспомнить, какая функция за что отвечает...полный изврат (имхо)

Тут уже холивар=) Что лучше, иметь 2000 строк в 1ом месте или продираться через 5 и более уровней наследования? Зависит от склада ума. Хотя я все-таки сторонник ООП.

имея нормальный редактор (даже тот же flash develop) навигация по классам не составит проблем (помоему теме пора во флейм =))

ООП рулит однозначно. Щас вот игруху делаю с коллективом... Не на flash блин)) Делаем физический движок. И знаете, если бы не классы, упорядоченность, дело бы не двигалось! А так в любое время можно не парясь посмотреть кусок кода, поправить функцию. Послать, наконец, новую версию дллельки сотоварищу для теста. Вобщем, ООП помогает реально. Как и хорошая оптимизация

Переехали.

А я проголосую за рациональность.
Вот есть мини таск - сделать лвл_эдитор для игрушки. Задание делать процедурно - несколько часов. Классами - больше дня. :)
В общем - косяк возникающий что в одном фрейме 27к строчек кода, возникает от декомпиляции всяких онлайн проектиков :rolleyes: (я такой делал здесь islandsworld.ru :) )
но в исходниках все акуратно и мило и удобно:cool: . все процедурно. но благодаря директиве #include все очень в исходниках удобно. И юзать ооп тама небыло никакой необходимости.
Щас к примеру у меня процедурно весь описан интерфес, в классы пихаю тоьлко игровые логики.
а еще, когда я пишу кросс-проектый код( одни и теже процедуры для flash и smartfox) то тогда только процедуры могу юзать. никаких ооп(в смарфоксе их нету).

Уже не могу без ООП, от этого простые вещи делаю порой очень долго =(

Надо подлечиться, пописав чуток на AS1:D
Для элементарных задач процедурное эффективнее

Чем больше флешеров будут писать код как попало (не ООП) и на чем попало (AS1/2) - тем больше шансов, что Silverlight в ближайшее время с горой сишников отберут у вас большую часть работы (проектов).

Потому призываю всех саморазвиваться и двигать флеш-платформу вперед. А чтобы быстрее это делать - надо выкинуть хлам из головы (это я про AS1/2 и процедуро-ориентированное программирование)

извените, но имхо, бред написали.
я вот к примеру кроме как в новостях о платформе Silverlight ничего не слышал. Во первых.:rolleyes:
Во вторых - спонсоров/заказчиков интересует только продукт. Не то как вы его написали, а то что вы его сделаете в срок(или быстрее), с заявлеными фичами. ас1,ас2,ас3 - это уже десятое дело.
в третьих. ас3. Хороший такой язык. Но если я делаю пасьянс, или паззл каконибудь очередной, то для меня очевидно что я его буду делать на флэше8, юзая ас2(игровая логика)/ас1(интерфейсы графические). потомучто так быстрее.:rtfm:
Важно понимать что ас3 это не эволюция. а революция. это новый вид =) а не продолжение старого. :)

Библиотека opengl реализована процедурно, без ООП. И использовать ее легко.

Все зависит от хорошей документации к коду. ;)

Почему каждый раз как в форумах объявляется личность впервые открывшая для себя ООП, то непременно открывает тему сравнения парадигм, методам обучения и пр. бояны.
40 лет прошло с появления ООП, написано куча книг, написано море статей, и вместо того, чтобы открывать и поддерживать бестолковый тред, ccwds, лучше почитайте их, попрактикуйтесь пару месяцев и все вопросы (которые у вас тут возникли именно из-за отсутствия всего вышеперечисленного) отпадут без чьей либо "форумской помощи".

Не думаю, что на AS2 у тебя получиться быстрее.

Если ты на самом деле понимаешь, что AS3 принципиально новый шаг в разработке на Flash/Flex, то не стал бы говорить, что на уродцах AS1/2 писать быстрее :)