| « ООП и Flash. Часть 3. О фанатиках | ООП и Flash. Часть 1. И вот сошлись огонь и лед, ООП и Macromedia Flash » |
ООП и Flash. Часть 2. Хитрецы против ООП
2006-11-21 12:12 , Рубрики: Flash Как уже говорилось в предыдущей части, часто отрицание самой идеи применения ООП для flash имеет причиной то, что разработчик не до конца понимает идеологию ООП.
Как понять, что вы еще не готовы к осмысленному выбору - ООП или не ООП? Как выявить в себе “хитреца", якобы использующего ООП, но реально процедурно программирующего в классах?
Вот несколько отличительных признаков. Проверь себя!
- Более 50 процентов ваших классов наследуются от MovieClip или UIObject. Хотя UIObject - это лишнее для вас, MovieClip как-то роднее.
- Вы считаете, что приватные свойства и методы придумали трусы и не затрудняете себя использованием индикаторов видимости.
- Причину, по которой вы бы использовали в своем проекте interface, даже трудно вообразить. Или вы вообще не знаете, что такое interface.
- Событийную модель Flash (да, это конструкция addEventListener) вы используете только в крайних случаях.
- Крайние случаи использования событийной модели у вас всегда связаны с использованием макромедийных компонент, впрочем, вы и так стараетесь их не использовать. Зачем? Ведь можно самому написать все эти компоненты, и они будут быстрее работать и меньше весить.
- Слова _parent, _root и _global не являются для вас ругательными или сколько-нибудь постыдными. Почему бы и не вызвать что-нибудь в _parent в нужный момент? Да и конструкции типа _parent. _parent. _parent не смущают вовсе, вы свободный человек в свободной стране - что хотите, то и вызываете.
- Вы не используете типизацию, а то и не знаете, что это такое.
- Повторное использование кода - это копирование целых классов и методов в новый проект с внесением незначительных изменений. А может и значительных, это как получится.
- Вы часто используете наследование. В ваших цепочках наследования порой насчитывается более 5 классов.
- Вы не знаете, что такое высокое зацепление, низкая связанность, инкапсуляция. полиморфизм.
- Вы не знаете, что такое шаблоны (паттерны) проектирования или просто их не используете.
Если, пробежавшись по этим признакам, обнаружили в себе и своем кода хотя бы один, то вы в весьма извращенной форме используете ООП или не используете его вовсе. Вы совершенно точно не имеете представления об ООП или имеете неправильные и далеко неполные представления. А значит можете открыть для себя очень много в мире программирования. 
Bookmark this article at
Трекбек адрес этой записи
URL трекбека (щелкните правой кнопкой мыши и скопируйте ссылку)
10 комментариев
Замечательный check list, я себя поймал на одном пункте
ооп это техника, которая требует некоторых, порой значительных вложений, но.... она с лихвой окупается при:
1) разработке больших проектов;
2) командной разработке;
3) повтором использовании кода и чужих библиотек;
4) применением рефакторинга и автоматического тестирования;
по поводу маленьких проектов, обычно если подсел на ооп, то уже не слезешь (думать нужно по другому), да и маленький проект всегда может вырасти или его можно будет
использовать повторно.
громоздкость as2 действительно раздражает, но это
потому что, он несколько недоделанный (нет многих полезных вещей например внутренних классов)
так что если вы ответили check list положительно, а as2 всё равно раздражает, то стоит задуматься об as3
ооп это техника, которая требует некоторых, порой значительных вложений, но.... она с лихвой окупается при:
1) разработке больших проектов;
2) командной разработке;
3) повтором использовании кода и чужих библиотек;
4) применением рефакторинга и автоматического тестирования;
по поводу маленьких проектов, обычно если подсел на ооп, то уже не слезешь (думать нужно по другому), да и маленький проект всегда может вырасти или его можно будет
использовать повторно.
громоздкость as2 действительно раздражает, но это
потому что, он несколько недоделанный (нет многих полезных вещей например внутренних классов)
так что если вы ответили check list положительно, а as2 всё равно раздражает, то стоит задуматься об as3
2006-11-21 @ 14:33
2 agahov
Командная разработка - как красиво и как почти недостижимо это звучит.
А что касается маленьких проектов, тот тут, мне кажется, уже можно пожертвовать какими-нибудь ООП-ными штучками, ну или хотя бы правилами хорошего тона в написании кода. Например, я иногда использую, открытые свойства, если они ни на чем не завязаны. Не использую посылку событий, если точно знаю, что для них есть всегда только один слушатель.
Я думаю, что главное все-таки писать так, чтобы потом при необходимости можно было провести ненапряжный рефакторинг, например, выделить класс и использовать его в другом проекте.
Да, отсутствие внутренних классов в as2 иногда прямо-таки подначивает к использованию Object в каком-нибудь срочном случае.
Командная разработка - как красиво и как почти недостижимо это звучит.
А что касается маленьких проектов, тот тут, мне кажется, уже можно пожертвовать какими-нибудь ООП-ными штучками, ну или хотя бы правилами хорошего тона в написании кода. Например, я иногда использую, открытые свойства, если они ни на чем не завязаны. Не использую посылку событий, если точно знаю, что для них есть всегда только один слушатель.
Я думаю, что главное все-таки писать так, чтобы потом при необходимости можно было провести ненапряжный рефакторинг, например, выделить класс и использовать его в другом проекте.
Да, отсутствие внутренних классов в as2 иногда прямо-таки подначивает к использованию Object в каком-нибудь срочном случае.
2006-11-21 @ 14:54
Комментарий от: tracker [Посетитель]
1. А в чем проблема наследования от Мувиклипа? для визуальных классов? а если я делаю компоненты второй версии, то как мне быть то?
4. Кривая реализация DOM Event, если не пользоваться компонентами можно пользоваться и чем то более приятным на глаз
someObject.focusIn.addListener (this, __focusInHandler);
Опять таки не показатель.
5. Event Driven Development это не показатель знания ООП, использование этой модели опять таки в зависимости от контекста проекта. В моем проекте есть модуль общения с сервером, кроме xml.onLoad не пользуется не один евент, тем не менее этой самый что не наесть чистый ООП. Насчет макромедийных компонент. Сразу видно влияние Кости Проект пользует ASWing как основу, и что я теперь не знаю ООП? да мало ли хороших компонент? А вы еще скажите разработчикам wallop.com что они не знают ООП так как не пользуют макромедийные компоненты.
9. Цитата из википедии на поиск по слову "полиморфизм"
"В объектно-ориентированных языках класс является типом данных. Полиморфизм реализуется с помощью наследования классов..." - http://ru.wikipedia.org/wiki/Полиморфизм_в_языках_программирования
Ага еще предъявите притензии к разработчикам WST, Swing, Struts, к разработчикам серверов, че мол у вас цепочка наследования больше 5 классов - не хорошо
Конечно, длинная цепочка создает некоторую зависимость (иногда и достаточное сильную) от класса предка, но опять таки... это не показатель, во всяком случае не так категорично: "Если, пробежавшись по этим признакам, обнаружили в себе и своем кода хотя бы один, то вы в весьма извращенной форме используете ООП или не используете его вовсе."
4. Кривая реализация DOM Event, если не пользоваться компонентами можно пользоваться и чем то более приятным на глаз
someObject.focusIn.addListener (this, __focusInHandler);
Опять таки не показатель.
5. Event Driven Development это не показатель знания ООП, использование этой модели опять таки в зависимости от контекста проекта. В моем проекте есть модуль общения с сервером, кроме xml.onLoad не пользуется не один евент, тем не менее этой самый что не наесть чистый ООП. Насчет макромедийных компонент. Сразу видно влияние Кости
Проект пользует ASWing как основу, и что я теперь не знаю ООП? да мало ли хороших компонент? А вы еще скажите разработчикам wallop.com что они не знают ООП так как не пользуют макромедийные компоненты.9. Цитата из википедии на поиск по слову "полиморфизм"
"В объектно-ориентированных языках класс является типом данных. Полиморфизм реализуется с помощью наследования классов..." - http://ru.wikipedia.org/wiki/Полиморфизм_в_языках_программирования
Ага еще предъявите притензии к разработчикам WST, Swing, Struts, к разработчикам серверов, че мол у вас цепочка наследования больше 5 классов - не хорошо
Конечно, длинная цепочка создает некоторую зависимость (иногда и достаточное сильную) от класса предка, но опять таки... это не показатель, во всяком случае не так категорично: "Если, пробежавшись по этим признакам, обнаружили в себе и своем кода хотя бы один, то вы в весьма извращенной форме используете ООП или не используете его вовсе."
2006-11-21 @ 19:51
2 tracker
1. Мне кажется, что если большинство классов унаследованы от мувиклипов, а следовательно визуальные, то скорее всего логика намешана с view. В этом пункте я только это подразумевала. Видимо не совсем ясно выразилась. Мне по жизни повезло работать с достаточно большим количеством flash-программистов, и случаи, когда почти все классы приложения являются мувиклипами и представляют собой дикую смесь отображения и логики, встречаются не сказать чтобы редко.
4. Имхо, addListener тоже относится к событийной модели Flash. Я ее не упомянула, спасибо, что напомнил.
5. Использовать что-нибудь, в принципе, логично всегда в зависимости от контекста проекта. Есть случаи, когда событийная модель не нужна. Но сделать вывод о том, надо ее использовать или нет для проекта, может человек только понимающий, что это такое.
По поводу влияния Кости, то да. Что тут скрывать. 
По поводу использования компонент макромедии, то тут я не говорила о том, что против использования компонент других разработчиков. Я в общем и целом, не разделяю стремления писать собственные аналоги уже существующих компонент. Тем более, у меня травма детства - я наблюдала, как одна команда написала для проекта свои компоненты (аналоги макромедийных), после чего разработка превратилась в ад.
По поводу использования альтернативный фрэймворков я согласна с Костей, что они имеют все-так ряд недостатков, а именно:
9. По поводу этого пункта, то если вынуть из контекста мою фразу про пять классов в цепочке наследования, то реально звучит странно. Но если ее рассмотреть в контексте того, что тема 'ООП и flash', то фраза приобретает немного другой смысл. Все-таки на flash редко делают большие проекты.
Я согласна, что если разработчик занимается созданием какой-то общей библиотеки или framework-а, то цепочки наследования могут быть длиннее, чем обычно. Просто хотелось признаки как-то более лаконично сформулировать, жаль, что получились некоторые двусмысленные.
1. Мне кажется, что если большинство классов унаследованы от мувиклипов, а следовательно визуальные, то скорее всего логика намешана с view. В этом пункте я только это подразумевала. Видимо не совсем ясно выразилась. Мне по жизни повезло работать с достаточно большим количеством flash-программистов, и случаи, когда почти все классы приложения являются мувиклипами и представляют собой дикую смесь отображения и логики, встречаются не сказать чтобы редко.
4. Имхо, addListener тоже относится к событийной модели Flash. Я ее не упомянула, спасибо, что напомнил.
5. Использовать что-нибудь, в принципе, логично всегда в зависимости от контекста проекта. Есть случаи, когда событийная модель не нужна. Но сделать вывод о том, надо ее использовать или нет для проекта, может человек только понимающий, что это такое.
По поводу влияния Кости, то да.
Что тут скрывать. По поводу использования компонент макромедии, то тут я не говорила о том, что против использования компонент других разработчиков. Я в общем и целом, не разделяю стремления писать собственные аналоги уже существующих компонент. Тем более, у меня травма детства - я наблюдала, как одна команда написала для проекта свои компоненты (аналоги макромедийных), после чего разработка превратилась в ад.
По поводу использования альтернативный фрэймворков я согласна с Костей, что они имеют все-так ряд недостатков, а именно:
- Они не поддерживаются держателем технологии,
- В их создание вложено, скорее всего, меньше средств, что чаще всего влечет их более низкое качество (меньшую оттестированность, документирование итд),
- Ими пользуется меньшее число разработчиков: соответственно те проблемы, которые возникнут с ними, скорее всего не будут отраженые в поисковиках итд.,
- Эти компоненты с большой долей вероятности не смогут сосуществовать в одном приложении с макромедийными. И не секрет, что на макромедийном фрэймворке создано большее количество расширений, которые нельзя будет использовать в проекте и придется дописывать их на данном фрэймворке. Так что все зависит от приложения, его размера, бюджета (в который должно входить изучение и освоение альтернативных фрэйворков) итд.
9. По поводу этого пункта, то если вынуть из контекста мою фразу про пять классов в цепочке наследования, то реально звучит странно. Но если ее рассмотреть в контексте того, что тема 'ООП и flash', то фраза приобретает немного другой смысл. Все-таки на flash редко делают большие проекты.
Я согласна, что если разработчик занимается созданием какой-то общей библиотеки или framework-а, то цепочки наследования могут быть длиннее, чем обычно. Просто хотелось признаки как-то более лаконично сформулировать, жаль, что получились некоторые двусмысленные.
2006-11-22 @ 11:46
По моему UIObject во многом предпочтительней MovieClip'а, хотя бы из за invalidate() и EventDispatcher'а
2006-11-22 @ 17:45
Ответ для Nirth
Согласна. Сама плюс к вышеперечисленному считаю полезными такие фичи как createChildren, doLater (что поделать - всякое в жизни бывает), createClassChildAtDepth, createClassObject, общий интерфейс для визуальных элементов приложения и др.
Согласна. Сама плюс к вышеперечисленному считаю полезными такие фичи как createChildren, doLater (что поделать - всякое в жизни бывает), createClassChildAtDepth, createClassObject, общий интерфейс для визуальных элементов приложения и др.
2006-11-22 @ 18:04
Комментарий от: juice [Посетитель] 
7 из 10, вот же блин Можете посоветовать какой-нибудь учебный материал про миграцию в ооп-ас2-ас3?
Можете посоветовать какой-нибудь учебный материал про миграцию в ооп-ас2-ас3?
2006-11-23 @ 13:02
Да... я "хитрец"
и не вижу в этом ничего плохого
)
и не вижу в этом ничего плохого
)
2006-11-23 @ 13:11
Ответ для juice
Миграцию в ООП можно осуществлять с помощью многих книжек, в которых есть главы про ООП. А главы эти обычно есть во всех книжках по объектно-ориентированным языкам.
Лично мне нравятся эти книжки:
Миграцию в ООП можно осуществлять с помощью многих книжек, в которых есть главы про ООП. А главы эти обычно есть во всех книжках по объектно-ориентированным языкам.
Лично мне нравятся эти книжки:
- Мук К. ActionScript 2.0. Основы. (Еще есть ActionScript 3 Мука на английском языке).
- Крэг Ларман Применение UML и шаблонов проектирования (на мой взгляд она трудновата для восприятия, но зато полезна)
- Гранд М. Шаблоны проектирования в Java
- Фаулер М., Бек К., Брант Д., Робертс Д., Апдайк У. Рефакторинг: улучшение существующего кода (эта книжка поможет не впасть в фанатизм)
2006-11-23 @ 14:23
Ответ для Ye-Su-Cin
В хитрости главное самого себя не обхитрить.
В хитрости главное самого себя не обхитрить.
2006-11-23 @ 15:43
RSS лента комментариев этой записиОставить комментарий
