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

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

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

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

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

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

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

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

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

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

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

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

можно

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

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

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

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

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

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