| « Интерфейсы в actionscript 2.0. Часть 1. Внешние модули | ООП и Flash. Часть 2. Хитрецы против ООП » |
ООП и Flash. Часть 3. О фанатиках
Противники ООП часто говорят о том, что ООП делает проект слишком большим. Мол, это может растянуть разработку небольшого клиента на неопределенное время - и когда у одних уже все работает и ‘летает’, у других только-только приложение начинает обрастать функционалом и работает заметно медленнее аналога. Однако когда дело доходит до изменений, уже первые в ужасе начинают кричать, что теперь все надо переписывать (и ведь переписывают, надо отдать им должное), а вторые вносят изменения и продолжают работать. Но ведь и до изменений дело не всегда доходит.
Тут как раз всплывает проблема убежденных и ярых сторонников ООП - когда дело так никогда и не доходит до изменений, классы редко используются повторно, а излишняя гибкость, в конце концов, оказывается ненужной и запутывает самих разработчиков. А что может быть хуже запутавшегося разработчика?
Появляется вопрос, как не впадать в фанатизм, чтобы не получилось ‘ООП - за что боролись, на то и напоролись’?
Для начала было бы не лишним выявить в себе ‘фанатика’? Привожу несколько признаков, которые помогут обнаружить фанатизм даже на ранних стадиях.
Особое внимание, пожалуйста, пункту пять. Проверь себя!
- Ваш девиз - все динамически, даже статическое GUI мы аттачим поэлементно, чтобы неповадно было.
- У вас можно задать практически все параметры, какие только мыслимы - от цвета фона приложения до размера и расположения любой буквы и кнопочки. В идеале это все грузится из внешнего конфигурационного файла.
- Вы свято следуете заповедям ‘высокое зацепление и низкая связанность’. У вас практически никто ни о ком ничего не знает - просто общество анонимных алкоголиков какое-то, а не приложение. Хотя с другой стороны все рассылают события о своем состоянии, так что между анонимными алкоголиками все-таки идет активное общение.
- Вы заранее думаете о будущем, стараетесь предусмотреть все возможные изменения и готовитесь к этому. Конечно, тратится время, но потом оно окупится сполна - пару строчек изменил и порядок.
- Иногда вы выделяете новый класс, интерфейс или делаете еще что-нибудь только потому, что так правильно. И вообще ‘так правильно’ и так ‘ОПП-шно’ часто встречаемый у вас аргумент.
- Рефакторинг проводите редко или никогда. Да и зачем, когда все изначально делаешь правильно?
- На построение архитектуры приложения у вас часто уходит много времени. Лучше сразу все продумать, чем потом исправлять. Составляете огромное количество UML-диаграмм, расписываете use-case-ы. В общем все делаете правильно.
- Вы используете рассылку событий всегда, даже в тех случаях, когда очевидна избыточность этого. Например, когда есть только один-единственный слушатель и реально можно использовать просто переданный единственный объект Delegate для обработки события. Иногда это правило распространяется только на текущее приложение, что связано со стремлением к единообразию в коде.
- Вы никогда не делаете public свойств. Можно сказать, что это принцип.
Выявив в себе фанатика, можно задуматься над этим. Впрочем, реальные фанатики вряд ли задумаются.
Зато могут быть уверены, что они - большая редкость в среде actionscrtipt программистов.
Тем, кто все-таки задумался, напоминаю, что излишняя гибкость и дальновидность может сделать приложение, написанное на actionscript более медленным. А медленные приложения подрывают веру заказчиков в способности технологии flash.
И не надо забывать, что все-таки разработка на flash - это быстрая разработка, поэтому бывает жизненно необходимо отказаться от лишней гибкости и правильности в пользу скорости.
Но отказываясь, от каких-то ООП-ых фич, будет не лишним отдавать себе отчет в том, к чему это может привести, чтобы потом не было мучительно больно вставлять эти фичи в полу работающее приложение. А вдруг вы хитрец c зачатками фанатизма?
И, конечно, отказ от чего-то очень индивидуален - для каждого приложения можно немного пересматривать свою систему ценностей и ориентиров. ![]()
В общем, использовать ООП или нет, и если использовать, то в какой мере, решать вам. И то делать этот выбор осмысленно или нет, тоже решать вам. Я же просто хочу напомнить, что всегда есть выбор. ![]()
Трекбек адрес этой записи
URL трекбека (щелкните правой кнопкой мыши и скопируйте ссылку)
30 комментариев
Не верю своим глазам. Я нашел человека, который пишет от том, что имеет прямое отношение к 10 из 24 часов в моих сутках
Константин - человек глубоко и далеко образованный, лично для меня вопрос о выборе технологии пока что не стоит (Flex не знаю почти)
Лично у меня еще не было проектов, в которых использование ООП не было бы оправдано. Скажу честно, что интерфейсы реально не использовал, но практически по всем пунктам (и по теории ООП) пытался сделать что-то адекватное
думаю вопрос в хороших инструментах... трудно в объектах писать в родном flash IDE да и долго.
да и технология, например в as3 подписаться на событие проще, чем использовать делегат в as2.
Качество, серьезно превосходящее запросы кончного пользователя, есть средство достижения высокой производительности.
пример японцы.
В японии компромисс между качеством и стоимостью не существует. Здесь почти все считают, что высокое качество приводит к сокращению стоимости
(Tajima and Matsubara 1984)
речь идёт о том качестве, которое разработчики добиваются для себя, своей личной мотиваци и самореализации.....
а борьба с этим это уже ошибка управления....
Не все могут свободно выбирать, какую технологию использовать - некоторые как я, птицы подневольные. Как заказчик скажет, так и надо делать. Вот заказчик говорит - делаем на flash и пожалуйста.
Да, я знаю, сейчас ты скажешь, что это дело разработчика показать заказчику, что на самом деле он хочет использовать flex, но имхо не всегда это можно осуществить.
В общем, пока что я не готова оставить flash дизайнерам, мультипликаторам, художникам и программистам, которые пишут в кадрах. Ведь не случайно actionscript пришел к свой true объектно-ориентированной реализации.
И еще. Программист - это сначала просто программист, а потом уже программист на чем-то конкретном. И у чего-то конкретного может быть своя специфика. Пока я пытаюсь мириться со спецификой flash.
Спасибо за поддержку.
А интерфейсы - очень полезная вещь. Например, при построении систем из большого количества отдельных модулей или при использовании объектов с похожим поведением, но совершенно различной логикой (когда наследование применить нельзя).
В родном flash IDE просто невозможно что-то писать с ощущением хоть минимального комфорта. Вообще, если кто-то там пишет, то снимаю шляпу - это, действительно, очень трудно.
А еще в одной книжке написано 'Быстро, качественно, дешево. Выберите любые два пункта'.
Саша, только не надо говорить, что я призываю к снижению качества. Наоборот, если уделять должное внимание специфике технологии, качество должно только повышаться.
Лучше скажи, что ты ответил на пункт 5?
А если же у тебя уже юольшой в этом опыт, ты все это делаешь на автомате, без усилий, четко знаешь что и к чему приводит - то почему бы не делать правильно ради правильности? Это определенный стиль. Утонченные манеры в повседневной жизни тоже чаще всего бесполезны. Но так или иначе на человека с действительно утонченными манерами, в котором это огранично, - приятно посмотреть. И общаться приятно.
бесполезны. Но так или иначе на человека с действительно
утонченными манерами, в котором это огранично, - приятно
посмотреть. И общаться приятно."
- Все-таки добрался ты, Костя, до книг по психологии,
как планировал (может уже забыл свои слова, я помню).
Наверняка под чутким руководством Junik,
эксперта в психологии. :-)
Передаю вам всем свой привет, не скажу что сильно
скучаю, но вспоминаю ВСЕХ очень часто.
Пишите, в блоге, буду читать, удачи вам. :-)
Делать правильно ради правильности - это, действительно, определенный стиль. Это своего рода педантичность.
У меня пока не настолько большой опыт разработки, чтобы я могла себе сказать - 'Все, Юля. Теперь просто можно идти по протоптанной дорожке, не задумываясь ни о чем.' Мне пока интересно пробовать новое в стиле программирования. И меня действительно смущают аргументы типа 'так правильно и так более ООП-но'. Другое дело, аргументы типа 'так более правильно, потому что...' или 'так будет более стабильно работать, потому что...'
качество оно не только функциональное
совпадение результата со всеми требованиями.
Качество, также бывает эстетическим, со временем начинаешь чувствовать ООП стиль, который обязательно оборачивается:
хорошей структурой - значит чётким пониманием.
лёгкой модифицируемостью.
повторным использованием
и т.п.
---------------------------------------------------
появляется твой вопрос, что иногда это не нужно,
а фантики всё равно делают!
так вот делают не обязательно для внешнего результата,
ещё и для внутреннего удовлетворения, что как не странно приводит к повышению производительности.
Думаю от применения ООП не может быть вреда.
и сделать по оопшному это всегда, что то значит иной раз это может быть не осознано.
Программирование в этом плане приближается к искусству, программа к картине где всё гармонично. Польза от искусства и гармонии не оценима.
Отказываться от хорошей структуры и лёгкой модифицируемости я не призываю. И более того считаю это губительным.
Я говорю о фанатичном стремлении к излишней гибкости, и стремления к возможному повторному использованию даже тогда, когда оно может реально никогда не пригодиться.
Все-таки на то и существует рефакторинг, чтобы в какой-то момент осознав, что что-то нужно использовать повторно, это выделить и использовать.
А мой пример ты не поняла. Если аристократ с утонченными манерами вдруг в один момент решит, что в этом случае они нецелесообразны, то он уже не аристократ. Как говорил знаток психологии Зигмунд Эн.: и сто крат не аристократ, а сто первый - как первых сто. Но это так, лирическое отступление, легкое увлечение психологией.
О чем это я? Забыл
Я стараюсь и не путать ООП и гибкость. И вообще говорила об _излишней_ гибкости и о фанатичном следованиям заповедям ООП.
И цитирую толковый словарь. Фанатизм - это доведенная до крайней степени приверженность к каким-либо верованиям или воззрениям, нетерпимость к любым др. взглядам.
Есть best practics (по книгам от мировых гуру, и так) и
единая политика от лица ведущего программиста (Костя).
Есть возможность пробовать, и на пробах, т.е. на своем
собственном опыте - постигать что-то, понимать отчетливо -
все плюсы и минусы того или иного подхода (Юля).
Сочетание всего этого - и дает лучший результат, имно.
Он служит для улучшения структуры кода в целом. А хорошая структура позволяет сделать что то ещё.
т.е заниматься этим можно и даже нужно без видимой причины.
Как минимум это даст удовлетворение от проделанной работы и полученного результата.
Так реально не только то, что можно пощупать, твоя радость от хорошего кода очень даже ощутима...
Например, когда есть только один-единственный слушатель и реально можно использовать просто переданный единственный объект Delegate для обработки события.
Кстати, в Cairngorm именно так все и происходит в случае передачи событий от интерфейса через фронт контроллер -- командам; строго одно событие -- одна команда (поправьте, если я неправ). Этим достигается некоторая четкость структуры, однозначность что ли.
Меня тут некоторые личности обзывают фанатегом %) И если следовать этим пунктам то из меня получается отличный фанатег. Это дает порой хорошые плюсы (? кто сказал плюсы) в больших проектах.
Просто очень приятно когда все сделано красиво со стороны кода и работает тоже красиво %). Я за японцев - делать нужно качественно даже когда этого не требуют.
Я тут недавно вывел свою теорию супер лени оправдывающую фанатизм:
Есть такая пословится, что ленивый все делает дважды. В програмщине она ох как права. Если поленится то часто приходится все переделывать(причем и не один раз). Поэтому лучше один раз хорошо все продумать и сделать с первого раза качественно чем потом 48 раз напрягаться. Ведь при хорошо продуманой архитектуре/проекте, в конечном результате работы получается меньше! А думать это вам не по клаве клацать. Думать можно и за пивом, и во сне...
А по поводу вопроса о Cairngorm, то один из них точно должен знать.
Что касается больших проектов, то, согласна - там нужна большая доля фанатизма, причем ото всех участников. Большие проекты лучше делать по всем правилам. И тем более, когда работает команда, то так всем проще.
По-моему, Хемингуэй писал, что есть два типа писателей - одни, долго думают, в процессе обстоятельно и долго пишут, им практически не приходится ничего потом исправлять. Другие пишут быстро - им пришла мысль, они написали, еще одна мысль - опять написали, пишут быстро, но зато потом много правят. Видимо с программистами также.
ООП фанатиков не надо лечить, вас надо оберегать как редкий вид.
Я становлюсь фанатиком (очень нравится). Решил переписать все исходники в оо-стиле. Столкнулся с проблемой: написал класс extend к movie clip, в нем есть метод resize, он вызывается на событие _root.onResize (stage слушает). Все работает как надо, только когда событие происходит, this относится уже к _root (а не к нужному объекту). Нет разницы, объект-listener или _root (все равно на рут). Пример:
class x {
private var sW:Number;
private var sH:Number;
//---
function x() {
this.sW = 0;
this.sH = 0;
_root.onResize = this.resize;
Stage.addListener(_root);
}
//---
private function resize(Void):Void {
this.sW = Stage.width ;
this.sH = Stage.height;
}
Я делаю неправильно? А-а-а, пожалуйста, подскажите что! Жизненно необходимо получать размеры рабочей области (по-человечески, без интервалов), да еще и вызывать другие методы из resize. Как вернуться к объекту?
var listener = this;
listener.onResize = this.resize;
Stage.addListener(listener);
Могу предложить еще вариант:
import mx.utils.Delegate;
var listener = new Object();
listener.onResize = Delegate.create(this, resize);
Stage.addListener(listener);
Ну если фанат небольших размеров, тогда вынужден будешь все сам писать, вместо того, чтобы пользоваться благами цивилизации.
Разве что кроме седьмого пункта
Bingo! Разве что кроме седьмого пункта
Ты - уникум. 8 из 9-ти.