Противники ООП часто говорят о том, что ООП делает проект слишком большим. Мол, это может растянуть разработку небольшого клиента на неопределенное время - и когда у одних уже все работает и ‘летает’, у других только-только приложение начинает обрастать функционалом и работает заметно медленнее аналога. Однако когда дело доходит до изменений, уже первые в ужасе начинают кричать, что теперь все надо переписывать (и ведь переписывают, надо отдать им должное), а вторые вносят изменения и продолжают работать. Но ведь и до изменений дело не всегда доходит.

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

Появляется вопрос, как не впадать в фанатизм, чтобы не получилось ‘ООП - за что боролись, на то и напоролись’?

Для начала было бы не лишним выявить в себе ‘фанатика’? Привожу несколько признаков, которые помогут обнаружить фанатизм даже на ранних стадиях. ;) Особое внимание, пожалуйста, пункту пять. Проверь себя!

  1. Ваш девиз - все динамически, даже статическое GUI мы аттачим поэлементно, чтобы неповадно было.
  2. У вас можно задать практически все параметры, какие только мыслимы - от цвета фона приложения до размера и расположения любой буквы и кнопочки. В идеале это все грузится из внешнего конфигурационного файла.
  3. Вы свято следуете заповедям ‘высокое зацепление и низкая связанность’. У вас практически никто ни о ком ничего не знает - просто общество анонимных алкоголиков какое-то, а не приложение. Хотя с другой стороны все рассылают события о своем состоянии, так что между анонимными алкоголиками все-таки идет активное общение.
  4. Вы заранее думаете о будущем, стараетесь предусмотреть все возможные изменения и готовитесь к этому. Конечно, тратится время, но потом оно окупится сполна - пару строчек изменил и порядок.
  5. Иногда вы выделяете новый класс, интерфейс или делаете еще что-нибудь только потому, что так правильно. И вообще ‘так правильно’ и так ‘ОПП-шно’ часто встречаемый у вас аргумент.
  6. Рефакторинг проводите редко или никогда. Да и зачем, когда все изначально делаешь правильно?
  7. На построение архитектуры приложения у вас часто уходит много времени. Лучше сразу все продумать, чем потом исправлять. Составляете огромное количество UML-диаграмм, расписываете use-case-ы. В общем все делаете правильно.
  8. Вы используете рассылку событий всегда, даже в тех случаях, когда очевидна избыточность этого. Например, когда есть только один-единственный слушатель и реально можно использовать просто переданный единственный объект Delegate для обработки события. Иногда это правило распространяется только на текущее приложение, что связано со стремлением к единообразию в коде.
  9. Вы никогда не делаете public свойств. Можно сказать, что это принцип.

Выявив в себе фанатика, можно задуматься над этим. Впрочем, реальные фанатики вряд ли задумаются. :) Зато могут быть уверены, что они - большая редкость в среде actionscrtipt программистов.

Тем, кто все-таки задумался, напоминаю, что излишняя гибкость и дальновидность может сделать приложение, написанное на actionscript более медленным. А медленные приложения подрывают веру заказчиков в способности технологии flash.

И не надо забывать, что все-таки разработка на flash - это быстрая разработка, поэтому бывает жизненно необходимо отказаться от лишней гибкости и правильности в пользу скорости.

Но отказываясь, от каких-то ООП-ых фич, будет не лишним отдавать себе отчет в том, к чему это может привести, чтобы потом не было мучительно больно вставлять эти фичи в полу работающее приложение. А вдруг вы хитрец c зачатками фанатизма? ;) И, конечно, отказ от чего-то очень индивидуален - для каждого приложения можно немного пересматривать свою систему ценностей и ориентиров. :)

В общем, использовать ООП или нет, и если использовать, то в какой мере, решать вам. И то делать этот выбор осмысленно или нет, тоже решать вам. Я же просто хочу напомнить, что всегда есть выбор. :)

Трекбек адрес этой записи

URL трекбека (щелкните правой кнопкой мыши и скопируйте ссылку)

30 комментариев

Комментарий от: Konstantin Kovalev [Учаснег] Email · http://riapriority.com/blogs/constantiner.php
Надо не думать - использовать ООП или не использовать. А надо думать, какую технологию использовать для создания приложения. Или какой фрэймворк. Ну и все проблемы, описанные выше, превосходно решает Flex (стоит лишь пожалеть о старом и недальновидном решении применения Flex 1/1.5 лишь для серверного компилятора с ужасным лицензированием) с его фрэймворком. Как бы надо оставить Flash тем, для кого он и предназначался: дизайнерам, мультипликаторам, художникам и программистам, которые пишут в кадрах (ведь ничего в этом плохого нет если речь идет о презентациях/мультиках).
2006-11-23 @ 20:27
Комментарий от: Slon_vsapogah [Посетитель] Email · http://max.argosoft.ru
Отличный цикл постов про ООП и Flash.

Не верю своим глазам. Я нашел человека, который пишет от том, что имеет прямое отношение к 10 из 24 часов в моих сутках :)

Константин - человек глубоко и далеко образованный, лично для меня вопрос о выборе технологии пока что не стоит (Flex не знаю почти) :) Вопрос скорее в том, как жить с Flash-ом, на котором много всего уже понаписано.

Лично у меня еще не было проектов, в которых использование ООП не было бы оправдано. Скажу честно, что интерфейсы реально не использовал, но практически по всем пунктам (и по теории ООП) пытался сделать что-то адекватное :) И это себя полностью оправдывало.
2006-11-24 @ 00:27
мне быстрее выделить класс, чем через пять минут ломать голову, что же здесь происходит.

думаю вопрос в хороших инструментах... трудно в объектах писать в родном flash IDE да и долго.

да и технология, например в as3 подписаться на событие проще, чем использовать делегат в as2.




2006-11-24 @ 04:35
Читаю книжку "человеческий фактор" не удержался решил процетировать:
Качество, серьезно превосходящее запросы кончного пользователя, есть средство достижения высокой производительности.

пример японцы.
В японии компромисс между качеством и стоимостью не существует. Здесь почти все считают, что высокое качество приводит к сокращению стоимости
(Tajima and Matsubara 1984)

речь идёт о том качестве, которое разработчики добиваются для себя, своей личной мотиваци и самореализации.....
а борьба с этим это уже ошибка управления....
2006-11-24 @ 08:05
Ответ для Constantiner

Не все могут свободно выбирать, какую технологию использовать - некоторые как я, птицы подневольные. Как заказчик скажет, так и надо делать. Вот заказчик говорит - делаем на flash и пожалуйста.

Да, я знаю, сейчас ты скажешь, что это дело разработчика показать заказчику, что на самом деле он хочет использовать flex, но имхо не всегда это можно осуществить.

В общем, пока что я не готова оставить flash дизайнерам, мультипликаторам, художникам и программистам, которые пишут в кадрах. Ведь не случайно actionscript пришел к свой true объектно-ориентированной реализации.

И еще. Программист - это сначала просто программист, а потом уже программист на чем-то конкретном. И у чего-то конкретного может быть своя специфика. Пока я пытаюсь мириться со спецификой flash. :)
2006-11-24 @ 10:50
Ответ для Slon_vsapogah

Спасибо за поддержку. :) Очень приятно, что то, что мы пишем на riapriority интересно и нужно людям. :)

А интерфейсы - очень полезная вещь. Например, при построении систем из большого количества отдельных модулей или при использовании объектов с похожим поведением, но совершенно различной логикой (когда наследование применить нельзя).
2006-11-24 @ 10:53
Ответ для agahov

В родном flash IDE просто невозможно что-то писать с ощущением хоть минимального комфорта. Вообще, если кто-то там пишет, то снимаю шляпу - это, действительно, очень трудно.

А еще в одной книжке написано 'Быстро, качественно, дешево. Выберите любые два пункта'.

Саша, только не надо говорить, что я призываю к снижению качества. Наоборот, если уделять должное внимание специфике технологии, качество должно только повышаться.

Лучше скажи, что ты ответил на пункт 5? ;)
2006-11-24 @ 10:59
Комментарий от: Konstantin Kovalev [Учаснег] Email · http://riapriority.com/blogs/constantiner.php
А насчет пятого пункта все просто. Если ты прочитала и услышала где-то, что вот как-то вот так - это правильно. Но почему, ты точно не знаешь, да и в точности как там правильно - тоже не ведаешь, то и не стоит. Лучше на кошках тренироваться. Можно и на реальном проекте - если он позволяет.

А если же у тебя уже юольшой в этом опыт, ты все это делаешь на автомате, без усилий, четко знаешь что и к чему приводит - то почему бы не делать правильно ради правильности? Это определенный стиль. Утонченные манеры в повседневной жизни тоже чаще всего бесполезны. Но так или иначе на человека с действительно утонченными манерами, в котором это огранично, - приятно посмотреть. И общаться приятно.
2006-11-24 @ 12:15
Комментарий от: Евгений Н. [Посетитель] Email
"Утонченные манеры в повседневной жизни тоже чаще всего
бесполезны. Но так или иначе на человека с действительно
утонченными манерами, в котором это огранично, - приятно
посмотреть. И общаться приятно."

- Все-таки добрался ты, Костя, до книг по психологии,
как планировал (может уже забыл свои слова, я помню).

Наверняка под чутким руководством Junik,
эксперта в психологии. :-)

Передаю вам всем свой привет, не скажу что сильно
скучаю, но вспоминаю ВСЕХ очень часто.

Пишите, в блоге, буду читать, удачи вам. :-)
2006-11-24 @ 12:28
Ответ для Constantiner

Делать правильно ради правильности - это, действительно, определенный стиль. Это своего рода педантичность. :) И ясное дело, что со временем, уже лень задумываться о том, почему ты делаешь именно так, а не иначе. Но если человек 'четко знает что и к чему приводит', то он и понимает, какие вещи можно опустить без вреда (а то и с пользой) для приложения.

У меня пока не настолько большой опыт разработки, чтобы я могла себе сказать - 'Все, Юля. Теперь просто можно идти по протоптанной дорожке, не задумываясь ни о чем.' Мне пока интересно пробовать новое в стиле программирования. И меня действительно смущают аргументы типа 'так правильно и так более ООП-но'. Другое дело, аргументы типа 'так более правильно, потому что...' или 'так будет более стабильно работать, потому что...'
2006-11-24 @ 12:50
Так это и был мой ответ на пятый пункт:)

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

Качество, также бывает эстетическим, со временем начинаешь чувствовать ООП стиль, который обязательно оборачивается:
хорошей структурой - значит чётким пониманием.
лёгкой модифицируемостью.
повторным использованием
и т.п.
---------------------------------------------------
появляется твой вопрос, что иногда это не нужно,
а фантики всё равно делают!

так вот делают не обязательно для внешнего результата,
ещё и для внутреннего удовлетворения, что как не странно приводит к повышению производительности.

Думаю от применения ООП не может быть вреда.
и сделать по оопшному это всегда, что то значит иной раз это может быть не осознано.

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


2006-11-24 @ 14:28
Ответ для agahov

Отказываться от хорошей структуры и лёгкой модифицируемости я не призываю. И более того считаю это губительным.

Я говорю о фанатичном стремлении к излишней гибкости, и стремления к возможному повторному использованию даже тогда, когда оно может реально никогда не пригодиться.

Все-таки на то и существует рефакторинг, чтобы в какой-то момент осознав, что что-то нужно использовать повторно, это выделить и использовать.
2006-11-24 @ 14:46
Комментарий от: Konstantin Kovalev [Учаснег] Email · http://riapriority.com/blogs/constantiner.php
Юля, не путай ООП и гибкость. Закладывать излишнюю гибкость и писать ООП-стильно - это разные вещи.

А мой пример ты не поняла. Если аристократ с утонченными манерами вдруг в один момент решит, что в этом случае они нецелесообразны, то он уже не аристократ. Как говорил знаток психологии Зигмунд Эн.: и сто крат не аристократ, а сто первый - как первых сто. Но это так, лирическое отступление, легкое увлечение психологией.

О чем это я? Забыл :(
2006-11-24 @ 15:15
Ответ для Constantiner

Я стараюсь и не путать ООП и гибкость. И вообще говорила об _излишней_ гибкости и о фанатичном следованиям заповедям ООП.

И цитирую толковый словарь. Фанатизм - это доведенная до крайней степени приверженность к каким-либо верованиям или воззрениям, нетерпимость к любым др. взглядам.
2006-11-24 @ 15:23
Комментарий от: Евгений Н. [Посетитель] Email
Истина как всегда где-то по середине.

Есть best practics (по книгам от мировых гуру, и так) и
единая политика от лица ведущего программиста (Костя).

Есть возможность пробовать, и на пробах, т.е. на своем
собственном опыте - постигать что-то, понимать отчетливо -
все плюсы и минусы того или иного подхода (Юля).

Сочетание всего этого - и дает лучший результат, имно.
2006-11-24 @ 15:34
Рефакторин как раз не должен добавлять новой функциональности - по определению.

Он служит для улучшения структуры кода в целом. А хорошая структура позволяет сделать что то ещё.
т.е заниматься этим можно и даже нужно без видимой причины.

Как минимум это даст удовлетворение от проделанной работы и полученного результата.
Так реально не только то, что можно пощупать, твоя радость от хорошего кода очень даже ощутима...

2006-11-24 @ 15:56
Комментарий от: rost [Учаснег] Email · http://flash-ripper.com/
О, теперь я знаю, как зовут одного моего знакомого начинающего флексера :-)

Например, когда есть только один-единственный слушатель и реально можно использовать просто переданный единственный объект Delegate для обработки события.


Кстати, в Cairngorm именно так все и происходит в случае передачи событий от интерфейса через фронт контроллер -- командам; строго одно событие -- одна команда (поправьте, если я неправ). Этим достигается некоторая четкость структуры, однозначность что ли.
2006-11-24 @ 16:16
Комментарий от: __i [Посетитель] Email · http://the33cows.com
Все хорошо в меру, главное поймать эту границу "хорошо/плохо"

Меня тут некоторые личности обзывают фанатегом %) И если следовать этим пунктам то из меня получается отличный фанатег. Это дает порой хорошые плюсы (? кто сказал плюсы) в больших проектах.
Просто очень приятно когда все сделано красиво со стороны кода и работает тоже красиво %). Я за японцев - делать нужно качественно даже когда этого не требуют.

Я тут недавно вывел свою теорию супер лени оправдывающую фанатизм:

Есть такая пословится, что ленивый все делает дважды. В програмщине она ох как права. Если поленится то часто приходится все переделывать(причем и не один раз). Поэтому лучше один раз хорошо все продумать и сделать с первого раза качественно чем потом 48 раз напрягаться. Ведь при хорошо продуманой архитектуре/проекте, в конечном результате работы получается меньше! А думать это вам не по клаве клацать. Думать можно и за пивом, и во сне...
2006-11-24 @ 16:46
Ответ для rost

:) А у меня похоже аж два таких знакомых флексера. :)

А по поводу вопроса о Cairngorm, то один из них точно должен знать. ;) Надеюсь, что Костя заметит твой вопрос и ответит. :)
2006-11-24 @ 17:10
Ответ для __i

Что касается больших проектов, то, согласна - там нужна большая доля фанатизма, причем ото всех участников. Большие проекты лучше делать по всем правилам. И тем более, когда работает команда, то так всем проще.

По-моему, Хемингуэй писал, что есть два типа писателей - одни, долго думают, в процессе обстоятельно и долго пишут, им практически не приходится ничего потом исправлять. Другие пишут быстро - им пришла мысль, они написали, еще одна мысль - опять написали, пишут быстро, но зато потом много правят. Видимо с программистами также. :)
2006-11-24 @ 18:05
Комментарий от: tracker [Посетитель] Email
Oхххх, девушка вы со мной не знакомы? я болен... Кто нибудь знает где лечат ООП Фанатиков?
2006-11-25 @ 17:43
Ответ для tracker

ООП фанатиков не надо лечить, вас надо оберегать как редкий вид. ;)
2006-11-27 @ 10:54
Комментарий от: 7-й прохожий [Посетитель] Email · http://www.x-project.name/
Здравствуйте,

Я становлюсь фанатиком (очень нравится). Решил переписать все исходники в оо-стиле. Столкнулся с проблемой: написал класс 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. Как вернуться к объекту?
2006-11-28 @ 06:53
Комментарий от: 7-й прохожий [Посетитель] Email · http://www.x-project.name/
Ой, прошу прощения, туплю (понял, исправил, заработало).

var listener = this;
listener.onResize = this.resize;
Stage.addListener(listener);
2006-11-28 @ 10:04
Ответ для 7-й прохожий

Могу предложить еще вариант:

import mx.utils.Delegate;

var listener = new Object();
listener.onResize = Delegate.create(this, resize);
Stage.addListener(listener);
2006-11-29 @ 15:33
Комментарий от: 7-й прохожий [Посетитель] Email · http://www.x-project.name/
Спасибо. Значит так будет правильнее, усвоил. Только вот, еще я фанат оптимизации и небольших размеров, а класс делегирования весит 480 байт – вес половины моего класса (с полным функционалом).
2006-11-29 @ 17:01
Ответ для 7-й прохожий

Ну если фанат небольших размеров, тогда вынужден будешь все сам писать, вместо того, чтобы пользоваться благами цивилизации. :)
2006-11-29 @ 17:18
Комментарий от: 7-й прохожий [Посетитель] Email · http://www.x-project.name/
В том и есть кайфъ ))))
2006-11-29 @ 17:53
Комментарий от: __etc [Посетитель] Email · http://dev.etcs.ru
Bingo!
Разве что кроме седьмого пункта :)
2007-02-16 @ 11:12
Bingo! Разве что кроме седьмого пункта :)

Ты - уникум. 8 из 9-ти. :)
2007-02-19 @ 11:31

Оставить комментарий


Ваш email адрес. (Не будет показан на сайте.)

Ваш URL будет показан.
:!: :?: :idea: :) :D :p B) ;) :> :roll: :oops: :| :-/ :( :'( |-| :>> :yes: ;D :P :)) 88| :. :no: XX( :lalala: :crazy: >:XX
(Заменить прерывания строк на <br />)
(Имя, email и сайт)
(Разрешить пользователям посылать вам сообщения (ваш email не отображается).)
3 + 2 + 7 - 1?
antispam test

Вы можете использовать OpenID чтобы предоставить ваше имя, email и url.