|
|
|||||
don't panic!
Регистрация: Aug 2001
Сообщений: 4,121
|
"Хорошего" ООП не существует. Как и "хорошего" кода.
Ну, то есть, вообще. Нет его. Есть только код, который решает задачу хорошо или решает задачу плохо. И есть код, который решает задачу еще лучше или еще хуже. А просто "хорошего" кода, как и "хорошего" ООП не существует. В задачу может входить читаемость кода для многих участников команды. А может и не входить. Может даже входить перелом мозга. Может входить легкая модифицируемость (омг) или реюзабельность (втф). А может и не входить. Короче, если код идеально решает задачу, которая перед ним поставлена -- он хороший, хоть тресни. И ООП в нем хорошее, хоть изойди зелеными пятнами. PS: еще раз, "хорошего" ООП не существует. Последний раз редактировалось Nox Noctis; 23.04.2009 в 14:03. |
|
|||||
.grin! wuz here
|
Внесу пять копеек, которые, вероятно проскакивали, но нить длинная.
К слову о решаемых и не очень задачах. У нас есть задача. И у этой задачи всегда есть очень много способов решения. При оценке его качества стоит сперва исходить из приоритетов. То есть в применении к коду, у него есть несколько критериев: 1) Читабельность 2) Простота (в противоположность избыточности) 3) Расширяемость 4) Независимость от внешних факторов (универсальность) 5) Соответствие стандартам 6) Скорость выполнения 7) Стилистика именования 8) Абстрактная элегантность В разных случаях приоритеты по критериям разные, более того, приоритеты могут меняться со временем и способом применения в конкретном случае. Приводить примеров не стану, поскольку просто лень, но если что, это не так сложно. Так вот, термин "хорошее ООП" чаще расставляет приоритеты примерно так как было указано выше. Не факт что этот порядок лучший. Кроме прочего этот порядок хорош в применении к архитектуре в целом, но никак не к реализации функций "черных ящиков", если те выполняют свою работу хорошо.
__________________
Breakcore them all! Последний раз редактировалось KidsKilla; 31.03.2009 в 17:57. |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Если второе - мне не понятно, почему он не на первых позициях.
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
ветеран форума
|
Цитата:
Сверхбыстрый код пишется как низкоуровневый. Он зачастую некрасив, неудобен в модификации и т п
__________________
4am is time to rock |
|
|||||
Регистрация: Feb 2010
Сообщений: 11
|
насколько я понял, компилировать в swf можно разными средствами? какой компилятор и с какми настройками самый строгий к ситнаксису и ОО модели?
|
|
|||||
Modus ponens
|
Ох елки, эта тема уже немного так подустарела... Ну вобщем, компиляторов 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 вообще не обязывает писать в классах и т.п. Технически флексовые компиляторы поддерживают и "безклассовый" код, но так просто никто не пишет потому что не удобно.
__________________
Hell is the possibility of sanity |
|
|||||
Banned
Регистрация: Jun 2009
Сообщений: 298
|
млин столько флуда ппц
ООП или его отсутствие != плохой программер. Есть задачи, в которых ООП просто не нужен, как факт, а есть в которых нужно частичное ООП, есть где нада вложить максимум и т/д/. Все зависит от задачи. Элементарный пример, решили в своем движке написать систему ГУЯ, для реализации всего в одном классе, потребуется очень много времени и ориентироваться в данном коде будет сложно ! Сделать классы: Text Button и прочее, отдельно не зависимо друг от друга, не лучший вариант, потому, что, как минимум прийдется дублировать кучу иерархических функций и т/д/. Лучший выход создать все в классах, но например так DisplayObject от него наследуються Text Button и прочее. Пример когда нафиг ООП не сдалось - простая галерея, смысл в ней делать наследованние и выносить все в классы? ( конечно если разговор идет о простой, конечной галереи ) это только запутает или мы пишем демку где вращается один куб, смысл в этой демке делать кучу классов и наследованний ? Проще говоря, если в задаче 10 строчек кода и все относятся к одному логическому концепту, использования ООП по большей части будет "модой", тогда, как если вы просто не хотите дублировать кучу кода + нужно явно разделить, что-то на что-то, уровень ООП будет пропорционально зависеть от читаемости/понятности/возможности модификации/без глючного использования/логичности кода PS Дочитал сообщение wvxvw и подчеркну последнюю фразу: "но так просто никто не пишет потому что не удобно.". ООП в первую очередь придуманно и используется чтобы упростить код, а не потому что программер крутой и это "модно" Последний раз редактировалось Artic; 14.02.2010 в 19:21. Причина: очепятки |
|
|||||
Регистрация: Feb 2010
Сообщений: 11
|
большое спасибо за развернутый ответ
я понимаю, что компиляции и тема ОО не связаны если я верно представляю, то все эти компиляторы различаются требованиями к синтаксису и фичами IDE. но на одном исходном AS коде байткод-то они должны выдавать одинаковый??? |
|
|||||
Modus ponens
|
Ну, скажем так, в теории - да, одинаковый, на практике, если вы не любитель радикально поэксперементировать с компилятором, то тоже скорее всего не столкнетесь с такими вещами. Но некоторые отличя все таки есть, но это не такие отличя как MinG - MSVC и тому подобное, програмируя на AS можно спокойно о них не знать и не задумываться.
__________________
Hell is the possibility of sanity |
Часовой пояс GMT +4, время: 19:20. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|