Nemo_c, а почему я должен был найти себя? если бы я нашёл в этом списке себя, поверьте, ответ был бы совершенно жругим :)

BlooDHounD, __etc простите .. меня действительно интересует вопрос чем
(какими критериями) меряют гм не знаю как назвать даже правильно... объектно ориентированый код...
а так же ... вот приходит к вам в TimeZero устраиваться работать программист.. как вы понимаете насколько он разбирается в ООП и шаблонах проектирования?
Как вообще глядя на код можно понять разбирается человек его писавший в ооп и шаблонах проектирования?
PS.
to всяким рода советчикам. которые рекомендуют что ли бо почитать.... я специально задаю такие тупые вопросы и прикидываюсь лантухом... что бы больше узнать и понять в этом вопросе. Рекомендуемую литературу либо уже давно прочёл либо читаю и перечитываю....

Можно. Код — это досье.
Есть люди, которые клали болт на принципы ООП. Есть люди, которые их используют, но не потому что знают (не знают), а потому что так модно и «правильно». Есть те, кто используют ровно столько принципов (и самое главное, понимают их, а не лепят по шаблону), сколько необходимо в данной ситуации, не теряя здравый смысл.

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

У меня иное мнение. :quiet:

а как понять по коду, разбирается человек в ооп или нет? куда смотреть?
чем мерить?

BlooDHounD
вы эта... противоречите генеральной линии партии :rtfm:
http://www.flasher.ru/forum/showthread.php?t=113133
отсюда
:D:p

разбираться и в том и том, это не значит: ООП = шаблоны проектирования.

Визуально. По оформлению, по логике, да по всему. Мерять своим собственным опытом надо или по некоторому эталону (или шаблону скорее), который формируется со временем.

Видимо у вас есть некоторый эталон\ы(или опять же некоторые критерии - правила), с которыми вы сравниваете код написанный другим программистом и уже затем делаете вывод насколько человек компетентен... вот бы узнать эти ваши эталоны.:rolleyes:

to BlooDHounD

конечно это абсурд :-) шаблоны это скорее костыли которые используют вначале что бы научится ходить (кстати авторы книг по "шаблонам" об этом вроде даже упоминают )

Вы что, ведь холивор будет.

Ух ты, тема получила продолжение! =)
Ну, мне тут вот такое сравнение пришло в голову:
Прыжки в высоту: до, кажется 60-х годов прыгали "ножницами", потом придумали прыгать "перекидным". Планка рекордов сразу поднялась сантиметров на 20. Похожая картина есть и тут:
Была одна теоретическая база, она сменилась, это позволило что-то улучшить =) Но ООП это всего лишь теория, ее можно только сопоставить с другой теорией, а хороший результат зависит от исполнителя. В этом отношении, шаблоны проэктирования - тренировки, но тренировки тоже придумывают иcxодя из каких-то усредненных показателей, и не факт, что тренируясь по одной системе вы достигнете тех же результатов, что и по другой, ну и уж темболее не по индивидуальной. Шаблон проэктирования, это скорее запись о том, как быстро решить тривиальную задачу. Но, естесственно, надо уметь сразу оценить, а на сколько задача тривиальна и подходит для решения с помощью этого шаблона, а это уже опыт / практика...
Ну и показатель хорошего кода, это все-таки, отсутствие багов, стабильность, быстродействие и понятность. А то, как кто этого добивается - уже личное дело каждого =)

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

Не будет, секретов не выдаем. :quiet:

Свой гвоздь вобью...
Та книга, из которой автор пример привел, имхо очень достойная (я в ООП не силен - поэтому это мнение новичка). Там нет возвращаемого типа и прочих премудростей потому что это самое начало - дальше интересней. У Мука так же, кстати, книга построена.
__etc, BlooDHounD, можно вопрос - вот вы на что смотрите, когда принимаете человека на работу (если вы этим занимаетесь)? Судя потому что объявление о вакансии висит достаточно долго, требования у вас высокие.

Волгоградец, я обычно смотрю на стол.

Мдааа. Опасные люди работают в TimeZero...

Очень интересное определение, но я думаю человек хотел спросить практических примеров …Другими словами понять что такое хорошо, а что такое плохо…

Читайте AS 3.0 Мука , там очень хорошие примеры общепринятого(относительно) стиля.

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

либо ты не растешь. Лучше через какое-то время обнаружить свой код отвратительным :)

Я изучал ООП на с++: AS, java, c# — производные концепций с++ и смалтока, программирование по ООП не значит "самое лучшее", во многих случаях С лучше чем С++, процедуры — лучше чем классы. Функционал(лисп etc) — лучше чем ООП.
НО:
видел такое на AS3 (сегодня)
ф4 кроме Map_clip ничего не показывает, т.к. Map_clip:*
Как сказать? Слов нет.

ну забил чувак на строгую типизацию. Зато FB ошибок не выдаёт при присваивании :-)))) если повсеместно такое насаждать.

Дело не в этом. это и есть пример плохого ООП
в хорошем (нормальном) конструкция
должна была сразу сократиться до
А то и вообще убрана или перенесена вниз по иерархии.

вот почему я не люблю (в большинстве случаев) динамические классы

Ну, имелось ввиду, что ты постоянно занимаешься флешем и постоянно черпаешь что то новое.)

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

В ТЗ обычно описан необходимый результат.
Дальше есть 2 типа программеров.
1) которые делают результат по ТЗ и дальше хоть, конь не валялся, и
2) которые знают что ТЗ поменяется скоро и придется переделывать ( или вообще такой вариант возможен).

Что это означает, я не понял?

Непереводимая игра слов некоторых народностей, означает примерно то же, что "хоть кол на голове теши" или" хоть партизаном назови" или даже " после нас хоть потоп" и самое интересное :" да мне побарабану"

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

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

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

"Хорошего" ООП не существует. Как и "хорошего" кода.
Ну, то есть, вообще. Нет его.

Есть только код, который решает задачу хорошо или решает задачу плохо. И есть код, который решает задачу еще лучше или еще хуже. А просто "хорошего" кода, как и "хорошего" ООП не существует.

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

Короче, если код идеально решает задачу, которая перед ним поставлена -- он хороший, хоть тресни. И ООП в нем хорошее, хоть изойди зелеными пятнами.

PS: еще раз, "хорошего" ООП не существует.

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

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

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

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

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

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

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

насколько я понял, компилировать в swf можно разными средствами? какой компилятор и с какми настройками самый строгий к ситнаксису и ОО модели?

Ох елки, эта тема уже немного так подустарела... Ну вобщем, компиляторов 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 вообще не обязывает писать в классах и т.п. Технически флексовые компиляторы поддерживают и "безклассовый" код, но так просто никто не пишет потому что не удобно.

млин столько флуда ппц

ООП или его отсутствие != плохой программер.
Есть задачи, в которых ООП просто не нужен, как факт, а есть в которых нужно частичное ООП, есть где нада вложить максимум и т/д/. Все зависит от задачи.

Элементарный пример, решили в своем движке написать систему ГУЯ, для реализации всего в одном классе, потребуется очень много времени и ориентироваться в данном коде будет сложно !
Сделать классы:
Text
Button
и прочее, отдельно не зависимо друг от друга, не лучший вариант, потому, что, как минимум прийдется дублировать кучу иерархических функций и т/д/.
Лучший выход создать все в классах, но например так
DisplayObject от него наследуються
Text
Button
и прочее. Пример когда нафиг ООП не сдалось - простая галерея, смысл в ней делать наследованние и выносить все в классы? ( конечно если разговор идет о простой, конечной галереи ) это только запутает или мы пишем демку где вращается один куб, смысл в этой демке делать кучу классов и наследованний ?

Проще говоря, если в задаче 10 строчек кода и все относятся к одному логическому концепту, использования ООП по большей части будет "модой", тогда, как если вы просто не хотите дублировать кучу кода + нужно явно разделить, что-то на что-то, уровень ООП будет пропорционально зависеть от читаемости/понятности/возможности модификации/без глючного использования/логичности кода

PS Дочитал сообщение wvxvw и подчеркну последнюю фразу: "но так просто никто не пишет потому что не удобно.".
ООП в первую очередь придуманно и используется чтобы упростить код, а не потому что программер крутой и это "модно"

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

Ну, скажем так, в теории - да, одинаковый, на практике, если вы не любитель радикально поэксперементировать с компилятором, то тоже скорее всего не столкнетесь с такими вещами. Но некоторые отличя все таки есть, но это не такие отличя как MinG - MSVC и тому подобное, програмируя на AS можно спокойно о них не знать и не задумываться.