Мои Пожитки.

Akopalipsis

Dukobpa3 Искренни Спасибо! я его у Вас уже искал, но для as3 не было.
А теперь я все Ваши слова посмотрю на деле и пойму за пол дня! Спасибо! Честно! Спасибо!

Dukobpa3

Без примеров понять сложно. А примеров там нету.
Постараюсь в скором времени тестов добавить и примеров.

Akopalipsis

Dukobpa3 был бы очень признателен.

Dukobpa3

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

MikroAcse

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

Dukobpa3

Рано пока
Оно еще раза три поменяется пока доделаю)

MikroAcse

Ну вот и прекрасно, я все равно пока не собираюсь делать новый проект. Мне Garden пока хватило.

Котяра

А с чем связан переезд?

Dukobpa3

Удобнее.
Ну и перешел на гит с меркуриала. Появился повод хостера сменить.

Inet_PC

На битбакете гит тоже есть

GBee

Дюк, расскажи про gd.eggs.mvc

Dukobpa3

Гитхаб удобнее как сервис.
И смена фейворит цвс была поводом на него спрыгнуть
Теперь у меня всё чоДко. Битбакет - халявные приватные репы. Гитхаб - паблик.

Ты меня раскусил Я просто не успел

Akopalipsis

Dukobpa3 у меня глупый вопрос, если бы у Вас было больше контроллеров,
то Вы бы тоже менеджер сделали?

Dukobpa3

Не понял вопрос.
Менеджер чего?

Akopalipsis

Вот смотрите, вью_менеджер у Вас отвечает за ссылки на созданные экземпляры и за добавление их в список отображения. Модель_менеджер просто за сохранение ссылок на экземпляры.
Ну а если будет больше одного контроллера и некоторые контроллеры не должны быть активными сразу.
Получается, что для них тоже нужен менеджер, хотя бы для того, что бы как в случаи с моделями, просто сохранять их для удобного обращения к экземплярам по константам. Так ведь?

Dukobpa3

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

Обычно такие варианты:
- все контроллеры всегда инитятся сразу (практически всегда так).
- те котороллеры которые должны инититься не сразу, а по требованию - скорее всего не контроллеры. (Возможно какой-то манагер чего-то или синглтон какой-то или еще чего, но практически всегда есть возможность сделать ЭТО не контроллером).
- А если контроллеры(Этот вариант по сути будет считаться косяком данного варианта архитектуры) - то дочерние к какому-то другому контроллеру, и инициализируются там где должны и в тот момент в который должны, а не в бустрапе.

Dukobpa3

Ну и я это выкладывал как раз для пинков. Так что если кому есть че сказать - не молчите.
Любой критике рад. Мож какие-то примеры как лучше тоже показать кто сможет.

in4core

Dukobpa3 - зачем? Что от этого изменится? Ты вроде не первый год пишешь, врядли будешь перестариваться.

Dukobpa3

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

Волгоградец

Вставлю пять центов. Так как достаточно долго сидел на растрировании анимации, решил посмотреть как делают крутые дядьки. Итак, gd.eggs.animationcache.Animation - отрисовка по _clip.nextFrame()? Работает? Я не помню сейчас в чек проблема, но мне пришлось слушать FRAME_CONSTRUCTED. Почему бы сразу клип не передавать, зачем вызывать getDefinitionByName, тем более нет проверок на наличие такого клипа. bitmapData.draw бросит эксепшон, если кадр пустой. Ну и по мелочи - метод называется buildCacheFromLibrary, а кэша нету - каждый раз для одинаковых клипов будут создаваться новый битмапы.

UPD: а, вижу - есть AnimationCache. Почему бы не сделать два в одном?

Dukobpa3

Во имя инкапсуляции и богов ООП. Один класс одна задача. Кешу кешово, мувику мувиково.
Задумывалось как фабрика. Которая выдает анимашки. Кеширует соответственно фабрика.

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

Это фейл, да. Свои библиотеки готовил сам потому с таким косяком не сталкивался. Давно писал.

Akopalipsis

Возможно у Dukobpa3'а и не поменяются взгляды, но ведь тут есть и другие

Dukobpa3

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

Итак.
Один из основных принципов фен-шуй в ООП - Один класс, одна задача, один уровень абстракции.
В случае с синглтоном мы на один класс возлагаем две задачи: Выполнение его собственннно предназначения функционального + контроль кол-ва экземпляров в системе (абстракция на уровень выше, задача другого уровня).
Соответственно косяк.

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

Я и раньше предпочитал какой-то внешний манагер классическому синглтону. Но как-то внятно объяснить почему так - не мог. Теперь вот всё стало на свои места.