Хорошее ООП?!

[MrPoma]

Это я знаю Не понял высказывание в контексте поста.

[Котяра]

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

[MrPoma]

Спасибо, теперь понял, что вы хотели сказать.

[KidsKilla]

Внесу пять копеек, которые, вероятно проскакивали, но нить длинная.

К слову о решаемых и не очень задачах.
У нас есть задача. И у этой задачи всегда есть очень много способов решения.
При оценке его качества стоит сперва исходить из приоритетов. То есть в применении к коду, у него есть несколько критериев:
1) Читабельность
2) Простота (в противоположность избыточности)
3) Расширяемость
4) Независимость от внешних факторов (универсальность)
5) Соответствие стандартам
6) Скорость выполнения
7) Стилистика именования
8) Абстрактная элегантность

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

Так вот, термин "хорошее ООП" чаще расставляет приоритеты примерно так как было указано выше. Не факт что этот порядок лучший. Кроме прочего этот порядок хорош в применении к архитектуре в целом, но никак не к реализации функций "черных ящиков", если те выполняют свою работу хорошо.

[miramax]

Код должен быть _ПОНЯТНЫМ_ и реюзабельным для _ДРУГИХ_ людей.
Остальное фигня.

ООП это абстрагирование данных и инкапсуляция.

Отсюда следует:
Хорошее ООП - это хороший ОДД, это когда понятно обрисованы классы и красиво накиданы интерфейсы их взаимодействия.

Коллеги легко понимают ваш код?
Им достаточно кинуть взгляд на паблик методы и интерфейсы ваших классов что бы понять как их заюзать ? - Тогда у вас хорошее ООП =)

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

[iNils]

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

Код должен быть _ПОНЯТНЫМ_ и реюзабельным для _ДРУГИХ_ людей.

Далеко не все люди работают в команде.
Во-вторых, ООП подразумевает, что в код лазить ДРУГИМ не нужно, есть public который отдает что им нужно

[Psycho Tiger]

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

6) Скорость выполнения

В смысле, скорость написания или именно выполнения кода?
Если второе - мне не понятно, почему он не на первых позициях.

[DarkLight]

Если второе - мне не понятно, почему он не на первых позициях.

Элементарно. Сложная объектная структура очень непроизводительна, но в >90% случаев ее производительность достаточна и преимущества по удобству проектирования и расширяемости окупаются. Простейший пример - Flex. По сути, это тяжеленная медленная штука, но скорость разработки, множество готовых решений и т п делают свое дело, и для множества бизнес-приложений внутренних сетей компаний и для RIA он стал отличной платформой.

Сверхбыстрый код пишется как низкоуровневый. Он зачастую некрасив, неудобен в модификации и т п

[wvxvw]

Ох елки, эта тема уже немного так подустарела... Ну вобщем, компиляторов AS кода существует так:
Флешевый компилятор (у него нет какого-то определенного имени, есть asc_authoring.jar, но это непосредственно код AS, это не линкер и не транскодер).
ASC - из Flex SDK - это то же самое, что и asc_authoring.jar, даже правильнее сказать - asc_authoring.jar - это кастомный билд ASC.
MXMLC - из Flex SDK - это все вместе, и линкер и декодеры и препроцессор MXML и т.п.
COMPC - из Flex SDK - практически то же самое, что и MXMLC, но создает SWC (библиотеки с прекомпилированым кодом, ресурсами и прочими дополнительными файлами).
Компиляторы из SDK традиционно принято называть указывая версию SDK, т.е. на сколько я знаю, первых версий MXMLC / COMPC не существует, или, даже если такие и есть, то это какие-то экспериментальные вещи. Практически второй версией тоже никто не пользуется. Т.е. как правило вы можете столкнуться с кодом для третей и четвертой версий.
Флешевый компилятор традиционно наименее строгий. Во флесковых хуже работа с ресурсами, но больше других полезных фишек, типа условной компиляции, настраиваемых предупреждений, использование в автоматизированых процессах и т.п.
Есть еще несколько програм которые в той или иной степени могут компилировать флешевый байткод, HaXe компилятор, например. Кроме этого есть еще много програм, которые умеют экспортировать графику во флешевый формат. По сути большинство векторных графических редакторов это могут в той или иной степени + есть специфически рассчитаные именно на SWF, SWFTools, SWFMill, SamHaXe, HXswfML.

Что до ОО модели - компиляторы такими вещами не занимаются это вообще на усмотрение разработчика. Строго говоря ECMA стандарт, который в большей части был принят за основу AS3 вообще не обязывает писать в классах и т.п. Технически флексовые компиляторы поддерживают и "безклассовый" код, но так просто никто не пишет потому что не удобно.

[codefather]

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

в той или иной степени могут компилировать флешевый байткод.

большое спасибо за развернутый ответ
я понимаю, что компиляции и тема ОО не связаны
если я верно представляю, то все эти компиляторы различаются требованиями к синтаксису и фичами IDE. но на одном исходном AS коде байткод-то они должны выдавать одинаковый???