Junik

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

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

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

2006-11-24 @ 04:35

Комментарий от: agahov [Учаснег]

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

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

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

2006-11-24 @ 08:05

Комментарий от: Junik [Учаснег]

Ответ для Constantiner

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

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

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

И еще. Программист - это сначала просто программист, а потом уже программист на чем-то конкретном. И у чего-то конкретного может быть своя специфика. Пока я пытаюсь мириться со спецификой flash.

2006-11-24 @ 10:50

Комментарий от: Junik [Учаснег]

Ответ для Slon_vsapogah

Спасибо за поддержку.

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

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

2006-11-24 @ 10:53

Комментарий от: Junik [Учаснег]

Ответ для agahov

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

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

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

Лучше скажи, что ты ответил на пункт 5?

2006-11-24 @ 10:59

Комментарий от: Konstantin Kovalev [Учаснег]

· http://riapriority.com/blogs/constantiner.php

А насчет пятого пункта все просто. Если ты прочитала и услышала где-то, что вот как-то вот так - это правильно. Но почему, ты точно не знаешь, да и в точности как там правильно - тоже не ведаешь, то и не стоит. Лучше на кошках тренироваться. Можно и на реальном проекте - если он позволяет.

А если же у тебя уже юольшой в этом опыт, ты все это делаешь на автомате, без усилий, четко знаешь что и к чему приводит - то почему бы не делать правильно ради правильности? Это определенный стиль. Утонченные манеры в повседневной жизни тоже чаще всего бесполезны. Но так или иначе на человека с действительно утонченными манерами, в котором это огранично, - приятно посмотреть. И общаться приятно.

2006-11-24 @ 12:15

Комментарий от: Евгений Н. [Посетитель]

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

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

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

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

Пишите, в блоге, буду читать, удачи вам. :-)

2006-11-24 @ 12:28

Комментарий от: Junik [Учаснег]

Ответ для Constantiner

Делать правильно ради правильности - это, действительно, определенный стиль. Это своего рода педантичность.

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

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

2006-11-24 @ 12:50

Комментарий от: agahov [Учаснег]

Так это и был мой ответ на пятый пункт

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

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

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

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

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

2006-11-24 @ 14:28

Комментарий от: Junik [Учаснег]

Ответ для agahov

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

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

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

2006-11-24 @ 14:46

Комментарий от: Konstantin Kovalev [Учаснег]

· http://riapriority.com/blogs/constantiner.php

Юля, не путай ООП и гибкость. Закладывать излишнюю гибкость и писать ООП-стильно - это разные вещи.

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

О чем это я? Забыл

2006-11-24 @ 15:15

Комментарий от: Junik [Учаснег]

Ответ для Constantiner

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

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

2006-11-24 @ 15:23

Комментарий от: Евгений Н. [Посетитель]

Истина как всегда где-то по середине.

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

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

Сочетание всего этого - и дает лучший результат, имно.

2006-11-24 @ 15:34

Комментарий от: agahov [Учаснег]

Рефакторин как раз не должен добавлять новой функциональности - по определению.

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

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

2006-11-24 @ 15:56

Комментарий от: rost [Учаснег]

· http://flash-ripper.com/

О, теперь я знаю, как зовут одного моего знакомого начинающего флексера :-)

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

Кстати, в Cairngorm именно так все и происходит в случае передачи событий от интерфейса через фронт контроллер -- командам; строго одно событие -- одна команда (поправьте, если я неправ). Этим достигается некоторая четкость структуры, однозначность что ли.

2006-11-24 @ 16:16

Комментарий от: __i [Посетитель]

· http://the33cows.com

Все хорошо в меру, главное поймать эту границу "хорошо/плохо"

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

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

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

2006-11-24 @ 16:46

Комментарий от: Junik [Учаснег]

Ответ для rost

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

А по поводу вопроса о Cairngorm, то один из них точно должен знать.

Надеюсь, что Костя заметит твой вопрос и ответит.

2006-11-24 @ 17:10

Комментарий от: Junik [Учаснег]

Ответ для __i

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

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

2006-11-24 @ 18:05

Комментарий от: tracker [Посетитель]

Oхххх, девушка вы со мной не знакомы? я болен... Кто нибудь знает где лечат ООП Фанатиков?

2006-11-25 @ 17:43

Комментарий от: Junik [Учаснег]

Ответ для tracker

ООП фанатиков не надо лечить, вас надо оберегать как редкий вид.

2006-11-27 @ 10:54

Комментарий от: 7-й прохожий [Посетитель]

Здравствуйте,

Я становлюсь фанатиком (очень нравится). Решил переписать все исходники в оо-стиле. Столкнулся с проблемой: написал класс 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-й прохожий [Посетитель]

Ой, прошу прощения, туплю (понял, исправил, заработало).

var listener = this;
listener.onResize = this.resize;
Stage.addListener(listener);

2006-11-28 @ 10:04

Комментарий от: Junik [Учаснег]

Ответ для 7-й прохожий

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

import mx.utils.Delegate;

var listener = new Object();
listener.onResize = Delegate.create(this, resize);
Stage.addListener(listener);

2006-11-29 @ 15:33

Комментарий от: 7-й прохожий [Посетитель]

Спасибо. Значит так будет правильнее, усвоил. Только вот, еще я фанат оптимизации и небольших размеров, а класс делегирования весит 480 байт – вес половины моего класса (с полным функционалом).

2006-11-29 @ 17:01

Комментарий от: Junik [Учаснег]

Ответ для 7-й прохожий

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

2006-11-29 @ 17:18

Комментарий от: 7-й прохожий [Посетитель]

В том и есть кайфъ ))))

2006-11-29 @ 17:53

Комментарий от: __etc [Посетитель]

· http://dev.etcs.ru

Bingo!
Разве что кроме седьмого пункта

2007-02-16 @ 11:12

Комментарий от: Junik [Учаснег]