Просмотр полной версии : Хорошее ООП?!
Хорошее ООП?!
Хорошее ООП в AS3 это вообще как? Вот смотрю я на код и как мне понять есть там хорошее ООП или нет. А что такое плохое ООП. Как вы сами отличаете xорошее ООП от «тухлого»? :eek:
хм... глубинный вопрос.. но лучше б это во флейм
Почему во флейм? меня интересует ООП с привязкой к AS3, а не про некое абстрактное ооп.
Хорошее ООП - это когда внесение каких-либо изменений, дописание модулей, добавление новой функциональности в проект не влечет за собой взрыв мозга.
ООП, это такой идеальный код, мега портабелный и мега оптимизированный, к которому нужно стремится в идеале.
Вопрос из серии, а как вы отличаете хороший третий закон Ньютона от плохого третего закона Ньютона...
mre, это абстрактное определение, нужна конкретика.
CEBEP, ООП, это такой идеальный код, мега портабелный и мега оптимизированный, к которому нужно стремится в идеале.
Как понять что ты уже пришёл к этому идеальному коду?
Как понять что ты идёшь в направлении мега портабельного и мега оптимизированного кода, а не в обратном направлении?
wvxvw, как ваше высказывание связано с моим вопросом?
Как понять что ты уже пришёл к этому идеальному коду? Это как горизонт, к нему стремишься, но никогда не достигнишь.
Как понять что ты идёшь в направлении мега портабельного и мега оптимизированного кода, а не в обратном направлении?Опыт подскажет.
Мультипостинг у нас запрещен.
iNils, я спрашивал про критерии.
Критерии идеального кода?
Критерии кода с хорошим ООП?
Критерии кода с плохим ООП
Критерии мегапортабельного кода?
другими словами горизонт мы видим, а критерии кода с хорошим ООП нет.
непонятно к чему стремиться...
Мультипостинг у нас запрещен.
Простите не знал
wvxvw, как ваше высказывание связано с моим вопросом?
ООП не бывает ни хорошим ни плохим, это абстракция явления, у которого нет такого критерия, как хороший / плохой. Вы же не можете сказать, что круг, это хорошо или плохо, вы можете нарисовать круг, который исходя из вашего определения о том, что такое "хороший круг" будет удовлетворять вашему определению на 100% / меньше % / не удовлетворять вовсе.
Ну возьмём к примеру создание Меню для сайта.
Хороший ООП, я думаю это такой, в данном случае:
Код можно использвать для создание разных меню без особых дороботок, все части кода по созданию менюшек и сабменюшек к друг другу не лезут, данные хранятся в xml и доступны для изменения структуры, не должна быть проблема создания меню как горизонтально и вертикально и т.д. что то вроде такого...
to wvxvw
Из книги "ActionScript 3.0 Design Patterns"
package
{
//This is BAD OOP -- No encapsulation
import flash.text.TextField;
import flash.display.Sprite;
public class NoEncap extends Sprite
{
public var dogTalk:String="Woof, woof!";
public var textFld:TextField=new TextField( );
public function NoEncap( )
{
addChild(textFld);
textFld.x=100;
textFld.y=100;
}
function showDogTalk( )
{
textFld.text=dogTalk;
}
}
}
package
{
//This is GOOD OOP -- It has encapsulation
import flash.text.TextField;
import flash.display.Sprite;
public class Encap extends Sprite
{
private var dogTalk:String="Woof, woof!";
private var textFld:TextField=new TextField( );
public function Encap( )
{
addChild(textFld);
textFld.x=100;
textFld.y=100;
}
function showDogTalk( )
{
textFld.text=dogTalk;
}
}
}
William Sanders и Chandima Cumaranatunge видимо не знакомы с вашей концепцией и поэтому пишут всякую "чушь" в своей книге.
to CEBEP.
Нужны критерии в терминах ООП и AS3(как то так), а своими словами вы сейчас говорите абстрактно.
>> William Sanders и Chandima Cumaranatunge видимо не знакомы с вашей концепцией и поэтому пишут всякую "чушь" в своей книге.
Именно так.
Да, и кавычки к чушь абсолютно ни к чему.
чё-то или я тупой, или приведенный выше код отличается только именем класса и конструктора о_О
добавлено
а, господи, нада кофе выпить, свойства сделал приватными. Но это не лучший пример инкапсуляции. Это как раз тот случай, когда "инкапсуляция ради инкапсуляции"
Не, это они пытались показать пример инкапсуляции... при этом наломав столько дров, что глядя на такой код, думается, что есть люди, которым лучше все-таки читать книги, а не писать их =)
Ну это ты перебарщиваешь. Где там дрова-то?
Как пример инкапсуляции - пример плохой. Нужно было что-то с геттерами и сеттерами придумать, где необходимо спрятать переменную, которую сеттер меняет, чтобы ее не трогали.
А так - обычный код, где там дрова-то? То, что showDogTalk не public функция?
Нет явного вызова super()
У метода отсутствует модификатор доступа / неймспейс.
У метода отстутствует возвращаемый тип.
Приватные переменные - это первый шаг на пути усложнения реюз / полиморфизма, в этом примере они должны были быть protected. (т.е. показав пример одного из принципов ООП тут же забили на остальные - офигительный мануал...)
Помоему, этого достаточно, чтобы закрыть эту книжку, и почитать чего-нибудь другое =)
ЗЫ. И вообще, классный мануал, если ты его просто копипастишь, компилируешь, и компилятор тебе ворнинг выдает? :D И это в двух с половиной строчках, чего ж там дальше-то будет? =)
при этом наломав столько дров, что глядя на такой код, думается, что есть люди, которым лучше все-таки читать книги, а не писать их =)
АГА, Значит плохой ООП код всё таки существует? как и существует плохой третий закон Ньютона.
Где в приведённом мною примере дрова наломаны? И как вы это определили?
показав пример одного из принципов ООП тут же забили на остальные
не, про остальные они пишут дальше.. это пример из начала книги.
Существует плохо написаный код - вы только что запостили 2 примера. А ООП это понятие, которое нельзя характеризовать с позиций дуализма - оно не на столько комплексное.
Приватные переменные - это первый шаг на пути усложнения реюз / полиморфизма, в этом примере они должны были быть protected. (т.е. показав пример одного из принципов ООП тут же забили на остальные - офигительный мануал...)
ну это не аргумент, это зависит от целей. Может он в этом случае именно хотел запретить детям видеть свойство.
У метода отсутствует модификатор доступа / неймспейс.
ну это тоже не аргумент. Он же не собственную библиотеку пишет, а простой пример.
Все остальное - да. Но вообще я, походу,сам плохой ООП-программер, потому что частенько эти вещи опускаю из-за лени. Следствие небольших проектов, которые пишу обычно исключительно один.
>> ну это тоже не аргумент.
Ого, ничего себе не аргумент? Это именно то место, где компайлер ругаться будет =)))) Модификатор доступа должен быть всегда, без исключений.
>> Может он в этом случае именно хотел запретить детям видеть свойство.
Запрещать детям видеть свойства родителей - это исключение из правила, и уж ни в коем случае не "типичная" ситуация, которую предположительно должен рассматривать мануал. Просто у чела привычка осталась с АС2 - вот и все объяснение, никакой другой логики в написаном нет.
В аттаче - то что думает по поводу вашего кода компилятор :)
Почему компайлер ругаться будет? У меня стоит strict mode и никто не ругается. По умолчанию используется internal, это всем известно, зачем мне это слово каждый раз писать.
Смотри аттач в предыдущем посте. И включи show warnings. Иногда очень помогает, особенно, если пользуешься ФДшным код-генератором или еклипс-мaнки ;)
эм. и warnings mode стоит включеный.
Ругается только на вещи типа
Warning: 1090: Migration issue: The onKeyDown event handler is not triggered automatically by Flash Player at run time in ActionScript 3.0. You must first register this handler for the event using addEventListener ( 'keyDown', callback_handler).
ты в чем компилируешь? Eclipse?
Компилирую mxmlc.exe ну, как бы не принципиально откуда... это в настройках компайлера. В ФД это можно задать в настройках проекта, в ФБ, почти наверняка тоже, ну, максимум, если нет - то подправить билд файл вручную, но, не думаю, что все на столько запущено =) В ФДТ тоже 100% должно быть =)
Это, первый ворнинг - 1085
второй - 1009
Смотреть весь список тут: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/compilerErrors.html
Зря чтоли люди мучались-писали? =)
ramshteks
19.09.2008, 19:07
мое карате лучше твоего))
Даешь хорошее ооп в каждый дом)
автору темы. Научись писать сначало хоть как нить с использованием ооп модели а потом поймешь что такое хорошо а что такое плохо)
изучай стандарты кодирования и прочее прочее прочее, но это на случай если у тебя есть цель быть лучшим ну ил на край быть лучше. а если так, для интересу праздного, то забей)
хорошее ооп это искусство а у искусства критериев нет.
я компилирую из flash ручками. Родной компилятор так не ругается.
А как это mxmlc стал неродным компилятором? :D Он даж более родной для АС3 =) Собственно, с ним по большей части все и работают... Это такой же продукт Adobe / MacroMedia как и Flash =) За что ж его так-то?
ЗЫ. Я могу попробовать компилировать ногами... например, но для этого мне прийдется залезть на стол и нажимать кнопки на клаве пальцами ног... ну, не знаю, ради эксперемента можно попробывать... но делать так постоянно я бы не стал =)
Во, у него даже иконка адобовская, заскринил для большей убедительности =)
я компилирую из flash ручками.Как же люди себя не любит.
Можно еще писать код дома, а компилить бегать к соседу этажом ниже или еще лучше в другой подъезд.
У нас сейчас минимум три редактора для кода: FlexBuilder, FDT и FD, который позволяют компилить прямо на месте, вообще не создавать fla или используя swc файлы.
дык я кодю в FD.
А компилирую alt-tab + ctrl-enter. Потому что компилировать не создавая фла мне показалось неудобным. Так же как делать интерфейсы mxml. Помоему ручками в ide намного проще разместить.
Chas, ну разместить один раз, а потом чего туда лазить
Fernando Costa
20.09.2008, 16:42
alt-tab + ctrl-enter == F6
По поводу MXML - я пока еще много чего о нем не знаю, но учусь =) И чем дальше, тем он мне больше нравится =) Пока, самая его прелесть в том, что лей-ауту можно довольно просто задавать шаблоны, т.е. можно, пользуясь, например, XML_MXML либой для PHP довольно быстро сделать лей-аут для уже готовых темплейтов, типа ВордПресса / Джумлы. Т.е. верстка во Флеше от верстки во Флексе отличается примерно на столько же, на сколько отличается верстка статической ХТМЛ странички, от настройки шаблона, чтобы он отображал разный контент в зависимости от настроек.
Т.е. представь, вот нужно сделать страничку, которая бы отображалась немного по-разному в зависимости от того, какие привилегии есть у юзера, который на нее смотрит - во флеше ты бы либо делал 2 разные флешки, либо одну, которая бы загружала в себя разный контент (но эту логику загрузки не всегда хочется держать на клиенте)... вобщем гемор, да и не по-научному =) А так - отправляется запрос к ПХП типа моястраничка.пхп?админ=тру и в ответ тебе отправляется флешка с админскими возможностями, а нет - так отправляется флешка, в которой этих возможностей нет. При этом ты верстал не флешку, а шаблон, в котором может быть сотня этих разных настроек... Вобщем, да чего я рассказываю =) это нужно пробовать самому, тогда становится понятнее =)
terbooter
22.09.2008, 10:31
Похоже автора (крутого флешера) развернули на собеседовании (страшным словом "плохое ООП") вот теперь он переполнен негативом и ищет правду -)
Теория ООП не привязана к какому-то языку, тк это абстракция более высокого уровня. Рекомендую почитать Гамму "Design Patterns"
Хорошее ооп приходит с опытом :). Вот я кодю особо об этом не задумывась, главное чтобы удобно было - а через некоторое время понимаю, что где-то можно было сделать лучше, правильнее. Но основных методик стоит придерживаться всегда.
FlexOkeks
23.09.2008, 09:22
Критерии кода с хорошим ООП?
Критерии кода с плохим ООП
Крошка сын к отцу пришел и спросила кроха, ООП есть хорошо, или все же плохо?
Хорошо это когда выгодно/умело используешь имеющиеся возможности/инструменты, в ООП это инкапсуляция, наследование и еще чего-то. А плохо, это когда мобильным телефоном забиваешь гвозди! Критерии могут быть разные в зависимости от конкретного кода/подхода ;)
Вообщем кроме wvxvw никто больше по делу не написал, отсюда сделаю вывод что остальные, написавшие, знают ООП так же как я, т.е. мало знакомы с ним или думают что знают. Спасибо.
BlooDHounD
23.09.2008, 23:52
Nemo_c, ммм .. тоесть не берётся в расчёт, интерес к теме? интерес беседы с автором? тупость вопроса? лень? нежелание флэймить? и ещё куча причин?
Вообщем кроме wvxvw никто больше по делу не написал, отсюда сделаю вывод что остальные, написавшие, знают ООП так же как я, т.е. мало знакомы с ним или думают что знают. Спасибо.
С подобными выводами вам в прокуратуру надо идти работать. :quiet:
BlooDHounD, повторю свою фразу которая видимо вас задела(хотя по идее не должна была).
отсюда сделаю вывод что остальные, написавшие, знают ООП так же как я Где вы здесь нашли себя, или я что то сказал про промолчавших?
Про тупость вопроса... очевидно я вопрос таким образом сформулировал не просто так :-)
С подобными выводами вам в прокуратуру надо идти работать. :quiet:
мне больше нравится отдел HR, или отдел при инвестиционной фирме который решает давать деньги под IT проект или нет :-) чувствую зарубил бы кучу чудных молодых проектов по причине не компетентности
реализаторов этих проектов... кучу бабла бы с экономил... :D:
BlooDHounD
24.09.2008, 00:48
Nemo_c, а почему я должен был найти себя? если бы я нашёл в этом списке себя, поверьте, ответ был бы совершенно жругим :)
BlooDHounD, __etc простите .. меня действительно интересует вопрос чем
(какими критериями) меряют гм не знаю как назвать даже правильно... объектно ориентированый код...
а так же ... вот приходит к вам в TimeZero устраиваться работать программист.. как вы понимаете насколько он разбирается в ООП и шаблонах проектирования?
Как вообще глядя на код можно понять разбирается человек его писавший в ооп и шаблонах проектирования?
PS.
to всяким рода советчикам. которые рекомендуют что ли бо почитать.... я специально задаю такие тупые вопросы и прикидываюсь лантухом... что бы больше узнать и понять в этом вопросе. Рекомендуемую литературу либо уже давно прочёл либо читаю и перечитываю....
Как вообще глядя на код можно понять разбирается человек его писавший в ооп и шаблонах проектирования?
Можно. Код — это досье.
Есть люди, которые клали болт на принципы ООП. Есть люди, которые их используют, но не потому что знают (не знают), а потому что так модно и «правильно». Есть те, кто используют ровно столько принципов (и самое главное, понимают их, а не лепят по шаблону), сколько необходимо в данной ситуации, не теряя здравый смысл.
BlooDHounD
24.09.2008, 01:37
Nemo_c, никак нельзя узнать по коду разбирается ли человек в ООП. даже нельзя узнать знает ли он теорию. некоторые хорошо про ООП рассказывают а на практике нифига не получается. а иногда наоборот. человек чувствует, как будет классно работать, но как объяснить он не может. шаблоны проектирования, на мой взгляд, вообще вредны для тру-ооп :)
Nemo_c, никак нельзя узнать по коду разбирается ли человек в ООП.
У меня иное мнение. :quiet:
У меня иное мнение. :quiet:
а как понять по коду, разбирается человек в ооп или нет? куда смотреть?
чем мерить?
BlooDHounD
шаблоны проектирования, на мой взгляд, вообще вредны для тру-ооп
вы эта... противоречите генеральной линии партии :rtfm:
http://www.flasher.ru/forum/showthread.php?t=113133
отсюда
— серьезно разбирается в ООП и шаблонах проектирования;:D:p
BlooDHounD
24.09.2008, 01:51
разбираться и в том и том, это не значит: ООП = шаблоны проектирования.
а как понять по коду, разбирается человек в ооп или нет? куда смотреть?
чем мерить?
Визуально. По оформлению, по логике, да по всему. Мерять своим собственным опытом надо или по некоторому эталону (или шаблону скорее), который формируется со временем.
Видимо у вас есть некоторый эталон\ы(или опять же некоторые критерии - правила), с которыми вы сравниваете код написанный другим программистом и уже затем делаете вывод насколько человек компетентен... вот бы узнать эти ваши эталоны.:rolleyes:
to BlooDHounD
ООП = шаблоны проектирования. конечно это абсурд :-) шаблоны это скорее костыли которые используют вначале что бы научится ходить (кстати авторы книг по "шаблонам" об этом вроде даже упоминают )
вот бы узнать эти ваши эталоныВы что, ведь холивор будет.
Ух ты, тема получила продолжение! =)
Ну, мне тут вот такое сравнение пришло в голову:
Прыжки в высоту: до, кажется 60-х годов прыгали "ножницами", потом придумали прыгать "перекидным". Планка рекордов сразу поднялась сантиметров на 20. Похожая картина есть и тут:
Была одна теоретическая база, она сменилась, это позволило что-то улучшить =) Но ООП это всего лишь теория, ее можно только сопоставить с другой теорией, а хороший результат зависит от исполнителя. В этом отношении, шаблоны проэктирования - тренировки, но тренировки тоже придумывают иcxодя из каких-то усредненных показателей, и не факт, что тренируясь по одной системе вы достигнете тех же результатов, что и по другой, ну и уж темболее не по индивидуальной. Шаблон проэктирования, это скорее запись о том, как быстро решить тривиальную задачу. Но, естесственно, надо уметь сразу оценить, а на сколько задача тривиальна и подходит для решения с помощью этого шаблона, а это уже опыт / практика...
Ну и показатель хорошего кода, это все-таки, отсутствие багов, стабильность, быстродействие и понятность. А то, как кто этого добивается - уже личное дело каждого =)
terbooter
24.09.2008, 09:06
Осмелюсь посоветовать еще раз. Начитались книжек, молодец,
теперь скорее-скорее надо все это применять на практике, тогда наступит более полное понимание и разные глупые вопросы исчезнут.
Вы что, ведь холивор будет.
Не будет, секретов не выдаем. :quiet:
Волгоградец
24.09.2008, 13:05
Свой гвоздь вобью...
Та книга, из которой автор пример привел, имхо очень достойная (я в ООП не силен - поэтому это мнение новичка). Там нет возвращаемого типа и прочих премудростей потому что это самое начало - дальше интересней. У Мука так же, кстати, книга построена.
__etc, BlooDHounD, можно вопрос - вот вы на что смотрите, когда принимаете человека на работу (если вы этим занимаетесь)? Судя потому что объявление о вакансии висит достаточно долго, требования у вас высокие.
BlooDHounD
24.09.2008, 18:20
Волгоградец, я обычно смотрю на стол.
Волгоградец
24.09.2008, 18:51
Мдааа. Опасные люди работают в TimeZero...
ООП не бывает ни хорошим ни плохим, это абстракция явления, у которого нет такого критерия, как хороший / плохой. Вы же не можете сказать, что круг, это хорошо или плохо, вы можете нарисовать круг, который исходя из вашего определения о том, что такое "хороший круг" будет удовлетворять вашему определению на 100% / меньше % / не удовлетворять вовсе.
Очень интересное определение, но я думаю человек хотел спросить практических примеров …Другими словами понять что такое хорошо, а что такое плохо…
Читайте AS 3.0 Мука , там очень хорошие примеры общепринятого(относительно) стиля.
Psycho Tiger
19.03.2009, 20:49
Если ты смотришь на код - и он тебе нравиться, в нем всё красиво - он хороший.
Если пройдет месяц, ты взглянешь на этот код и он до сих пор будет хорошим - значит, код действительно хороший :)
Fernando Costa
19.03.2009, 21:14
значит, код действительно хороший либо ты не растешь. Лучше через какое-то время обнаружить свой код отвратительным :)
Я изучал ООП на с++: AS, java, c# — производные концепций с++ и смалтока, программирование по ООП не значит "самое лучшее", во многих случаях С лучше чем С++, процедуры — лучше чем классы. Функционал(лисп etc) — лучше чем ООП.
НО:
видел такое на AS3 (сегодня)
Map_clip.map_y.left_top_dot.Transform.Init(X_max,Y_min);
ф4 кроме Map_clip ничего не показывает, т.к. Map_clip:*
Как сказать? Слов нет.
ну забил чувак на строгую типизацию. Зато FB ошибок не выдаёт при присваивании :-)))) если повсеместно такое насаждать.
ну забил чувак на строгую типизацию. Зато FB ошибок не выдаёт при присваивании :-)))) если повсеместно такое насаждать.
Дело не в этом. это и есть пример плохого ООП
в хорошем (нормальном) конструкция
Map_clip.map_y.left_top_dot.Transform.Init(X_max,Y _min)
должна была сразу сократиться до
Map_clip.mapTransformInit(xMax,yMin)
А то и вообще убрана или перенесена вниз по иерархии.
CrazyFlasher
20.03.2009, 11:39
вот почему я не люблю (в большинстве случаев) динамические классы
Psycho Tiger
20.03.2009, 16:57
либо ты не растешь. Лучше через какое-то время обнаружить свой код отвратительным :)
Ну, имелось ввиду, что ты постоянно занимаешься флешем и постоянно черпаешь что то новое.)
на мой взгляд бывает хороший или плохой код, который зависит от программиста, как он смог реализовать ТЗ с помошью ООП так и есть. (ООП - одно, а вот пользоваться им можно по разному, хорошо или не очень)
В ТЗ обычно описан необходимый результат.
Дальше есть 2 типа программеров.
1) которые делают результат по ТЗ и дальше хоть, конь не валялся, и
2) которые знают что ТЗ поменяется скоро и придется переделывать ( или вообще такой вариант возможен).
и дальше хоть, конь не валялсяЧто это означает, я не понял?
Непереводимая игра слов некоторых народностей, означает примерно то же, что "хоть кол на голове теши" или" хоть партизаном назови" или даже " после нас хоть потоп" и самое интересное :" да мне побарабану"
Это я знаю :) Не понял высказывание в контексте поста.
Означает, что (1) пишет код так чтобы обеспечивать результат по ТЗ, как его дальше сопровождать, изменять, портировать, расширять - не волнует
(2) знает (или привык писать так) что код надо будет дальше сопровождать, изменять, портировать, расширять.
Вот в этом и разница хороший ООП и не хороший.
Все писать на ООП не обязательно. я еще раз повторюся, что КОНЕЧНЫЕ реализции могут быть (и часто являются) процедурными или функциональными.
Но что касается распределенной по времени и исполнителям разработки: ООП маст хэв.
Спасибо, теперь понял, что вы хотели сказать.
Nox Noctis
28.03.2009, 03:36
"Хорошего" ООП не существует. Как и "хорошего" кода.
Ну, то есть, вообще. Нет его.
Есть только код, который решает задачу хорошо или решает задачу плохо. И есть код, который решает задачу еще лучше или еще хуже. А просто "хорошего" кода, как и "хорошего" ООП не существует.
В задачу может входить читаемость кода для многих участников команды. А может и не входить. Может даже входить перелом мозга. Может входить легкая модифицируемость (омг) или реюзабельность (втф). А может и не входить.
Короче, если код идеально решает задачу, которая перед ним поставлена -- он хороший, хоть тресни. И ООП в нем хорошее, хоть изойди зелеными пятнами.
PS: еще раз, "хорошего" ООП не существует.
KidsKilla
31.03.2009, 17:46
Внесу пять копеек, которые, вероятно проскакивали, но нить длинная.
К слову о решаемых и не очень задачах.
У нас есть задача. И у этой задачи всегда есть очень много способов решения.
При оценке его качества стоит сперва исходить из приоритетов. То есть в применении к коду, у него есть несколько критериев:
1) Читабельность
2) Простота (в противоположность избыточности)
3) Расширяемость
4) Независимость от внешних факторов (универсальность)
5) Соответствие стандартам
6) Скорость выполнения
7) Стилистика именования
8) Абстрактная элегантность
В разных случаях приоритеты по критериям разные, более того, приоритеты могут меняться со временем и способом применения в конкретном случае.
Приводить примеров не стану, поскольку просто лень, но если что, это не так сложно.
Так вот, термин "хорошее ООП" чаще расставляет приоритеты примерно так как было указано выше. Не факт что этот порядок лучший. Кроме прочего этот порядок хорош в применении к архитектуре в целом, но никак не к реализации функций "черных ящиков", если те выполняют свою работу хорошо.
Psycho Tiger
31.03.2009, 21:57
6) Скорость выполнения
В смысле, скорость написания или именно выполнения кода?
Если второе - мне не понятно, почему он не на первых позициях.
DarkLight
31.03.2009, 22:07
Если второе - мне не понятно, почему он не на первых позициях.
Элементарно. Сложная объектная структура очень непроизводительна, но в >90% случаев ее производительность достаточна и преимущества по удобству проектирования и расширяемости окупаются. Простейший пример - Flex. По сути, это тяжеленная медленная штука, но скорость разработки, множество готовых решений и т п делают свое дело, и для множества бизнес-приложений внутренних сетей компаний и для RIA он стал отличной платформой.
Сверхбыстрый код пишется как низкоуровневый. Он зачастую некрасив, неудобен в модификации и т п
codefather
14.02.2010, 16:40
Ого, ничего себе не аргумент? Это именно то место, где компайлер ругаться будет =))))
насколько я понял, компилировать в 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 и подчеркну последнюю фразу: "но так просто никто не пишет потому что не удобно.".
ООП в первую очередь придуманно и используется чтобы упростить код, а не потому что программер крутой и это "модно"
codefather
16.02.2010, 02:03
в той или иной степени могут компилировать флешевый байткод.
большое спасибо за развернутый ответ
я понимаю, что компиляции и тема ОО не связаны
если я верно представляю, то все эти компиляторы различаются требованиями к синтаксису и фичами IDE. но на одном исходном AS коде байткод-то они должны выдавать одинаковый???
Ну, скажем так, в теории - да, одинаковый, на практике, если вы не любитель радикально поэксперементировать с компилятором, то тоже скорее всего не столкнетесь с такими вещами. Но некоторые отличя все таки есть, но это не такие отличя как MinG - MSVC и тому подобное, програмируя на AS можно спокойно о них не знать и не задумываться.
Код должен быть _ПОНЯТНЫМ_ и реюзабельным для _ДРУГИХ_ людей.
Остальное фигня.
ООП это абстрагирование данных и инкапсуляция.
Отсюда следует:
Хорошее ООП - это хороший ОДД, это когда понятно обрисованы классы и красиво накиданы интерфейсы их взаимодействия.
Коллеги легко понимают ваш код?
Им достаточно кинуть взгляд на паблик методы и интерфейсы ваших классов что бы понять как их заюзать ? - Тогда у вас хорошее ООП =)
производительность, читабельность, стандартизируемость - это хороший код, к понятию хорошего ООП это не относится.
ООП хорошая штука, когда понимаешь, зачем он тебе нужен, и как пользоваться его свойствами.
Просто ООП ради ООП никому нах не сдалось.
Код должен быть _ПОНЯТНЫМ_ и реюзабельным для _ДРУГИХ_ людей.Далеко не все люди работают в команде.
Во-вторых, ООП подразумевает, что в код лазить ДРУГИМ не нужно, есть public который отдает что им нужно :)
Умные люди подсказали, что Хорошее ООП Можно померить Метриками кода :-)
http://www.ibm.com/developerworks/ru/edu/0108novich/section2.html
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
Кстати, нашел статью (древнюю, но тем не менее!) по поводу OOP - там сравниваются подходы в програмировани БД и ОО языках, и очень красиво объясняется когда не нужно использовать OOP.
По поводу ООП и хорошего кода, всё - же порекомендую почитать
Code Complete (http://www.piter.com/book.phtml?978546900822) и
Refactoring (http://www.ozon.ru/context/detail/id/1308678/)
ну и конечно Банду четырёх (http://www.ozon.ru/context/detail/id/2457392/)
Читать не как руководство к действию (авторы, кстати, тоже не настаивают на слепом и фанатичном использовании их методик), а как некую версию происходящего в мире "сферического кода в вакууме".
PsixokoT
07.04.2010, 11:48
Вообще программиста стоит оценивать не по знанию и умению пользоваться ООП, вот
http://docs.google.com/Doc?docid=d28gm4q_55n35dkht4 Только тяжело на том же самом собеседование по этой матрице определить кто сидит напротив вас.
DarkLight
07.04.2010, 23:05
Только тяжело на том же самом собеседование по этой матрице определить кто сидит напротив вас.
Хм, почему же. Грубо говоря, почти во всех случае волнуют не все пункты, а остальные более-менее можно проверить на часовом собеседовании с написанием одного куска кода и одним вопросом на тему "как бы Вы решили вот такую техническую задачу". А если программист предоставил пример кода на ревью до собеседования - вообще все замечательно.
orcpochta
01.05.2010, 03:21
Вот хорошее ООП - прямо чистый MVC)))
http://forumbgz.ru/user/upload/file363010.jpghttp://forumbgz.ru/user/upload/file363011.jpg
P.S. Кто эта безумно красивая девушка 8-ю постами выше???)))
drnet_ua
21.07.2010, 19:31
оффтоп
Вот хорошее ООП - прямо чистый MVC)))
P.S. Кто эта безумно красивая девушка 8-ю постами выше???)))
судя по TinEye это Lindsay Lohan (http://u4.popcornfor2.com/show/KGp458e0.jpg)
программирование по ООП не значит "самое лучшее"
Наверное, создание по идеальному ООП коду, сверхбыстрой бинарной программы, задача будущего: интеллектуальные компиляторы.
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.