|
|
|||||
Banned
[+4 24.02.14]
[+4 07.11.13] [+ 13.03.14] Регистрация: Mar 2013
Сообщений: 1,864
|
Цитата:
|
|
|||||
Для несложного сайта можно вообще не париться и использовать Loader и URLLoader - там где они нужны.
Потребность в отдельном сервисе возникнет там где нужна либо очередь, как писалось выше, либо какой-то кеш загруженых ассетов, чтоб второй раз не грузились. Если вы только учитесь то я бы рекомендовал не усложнять а именно так и сделать. Без сервиса, модуля или прочей абстракции. Разобраться с ролями в системе, а потом уже что-то общее выносить отдельно. Добавлено через 2 минуты Т.е. логика в том что имеет смысл добавлять новую сущность только тогда когда в ней есть необходимость. Когда необходимость возникнет - вы поймете. А пока не понимаете - она не нужна А на роль такого вот сервиса дефолтные флешоаве лоадеры вполне подходят
__________________
Кто к нам с чем для чего - тот у нас того от того. |
|
|||||
Banned
[+4 24.02.14]
[+4 07.11.13] [+ 13.03.14] Регистрация: Mar 2013
Сообщений: 1,864
|
Dukobpa3 Спасибо! я и не тороплюсь, как бы мне этого не хотелось.
я пока учу как сериализировать\десериализировать и набить этим модель. Как пойму, что на бессознательном уровне смогу понять ход работы, вернусь сюда или в ГЛОБАЛЬНУЮ тему ( на пятидесяти страницах ) и спрошу про механизм наполнения модели. А то вдруг что не так понял) Спасибо! |
|
|||||
[+1 25.10.13]
[+4 18.03.14] |
В интерфейсе между детьми я могу увидеть некоторый смысл, если дети и родитель выполняют общие функции для кого-то. Это очевидно. В случае же с МVC ядро самостоятельной роли не играет. Давайте еще придирки к моим словам.
Добавлено через 9 минут Цитата:
Так что процесс загрузки, тоже неоднозначен. Последний раз редактировалось Babylon; 09.08.2013 в 03:29. |
|
|||||
Регистрация: Aug 2013
Сообщений: 56
|
Babylon, логика вида определяется видом. Если виду надо загрузить последовательно, то он сам это и должен сделать. MC не должны иметь абсолютно никаких зависимостей от V. Иначе сам шаблон MVC теряет свой смысл. А в случае, если ассеты будет грузить не вид, то это прямая от него зависимость.
|
|
|||||
[+1 25.10.13]
[+4 18.03.14] |
То есть по вашему логика работы модели не должна влиять на процесс загрузки ассетов? Несогласен.
|
|
|||||
Пусть влияет.
Но не грузит. Этого можно добиться кучей методов. Например вью начнет грузить и отображать ассеты только по определенному месаджу из модели. Но модели абсолютно по барабану какие картинки будут нарисованы во вью, и как она их нарисует.
__________________
Кто к нам с чем для чего - тот у нас того от того. |
|
|||||
Регистрация: May 2010
Сообщений: 543
|
Цитата:
У любого начинающего может сложиться такое же странное и в корне неправильное представление об архитектуре из-за вашей лженауки об интерфейсах, xml'ях и ядре.
__________________
Вы грабите бедных людей. Парень со свирелью накажет вас. Хонгильдон (с) |
|
|||||
LoaderMax
BulkLoader И много других, достаточно загуглить. Не зачем велосипеды изобретать. Добавлено через 10 минут Цитата:
Главное приложение оболочка грузит в себя пачку плагинов. Каждый плагин это отдельный проект. Наследоваться от какого-то базового класса плугина глупо и неэффективно, будет куча конфликтов. Интерфейс - ок. В итоге родителю абсолютно пофигу как там реализован плугин, он будет работать с его интерфейсом. Пример два(не совсем родитель-дети, но без интерфейса плохо): Паттерн "стратегия". Например какой-то поиск пути несколькими методами, либо какая-то квестовая система, где одна задача решается пачкой методов. Для поиска пусти у нас есть интерфейс ИРасчетПути. В котором допустим есть метод getPath(cells:Array):Array - принимает массив ячеек карты, выдает массив ячеек по которым юнит может пройти. Далее мы реализовываем несколько методов расчета и встегиваем в нужный момент в нужное место в каком-то манагере. Для квестовой системы так же. Есть какой-то IConditionChecker. Например такой(из моего реального проекта): [Event(name = "complete", type = "flash.events.Event")] [Event(name = "change", type = "flash.events.Event")] public interface IConditionChecker extends IEventDispatcher { //===================================================================== // PUBLIC //===================================================================== function init(subtype:String, num:int, data:String, delta:Boolean):void; function update(status:int, data:BaseProtoData):void; function setCounter(counter:int):void; //===================================================================== // ACCESSORS //===================================================================== function get commandId():int; function get complete():Boolean; function get count():int; function get needCount():int; } Пример три, паттерн "команда". Интерфейс ICommand реализуется как вздумается. Можно обойтись базовой командой и ее наслоедовать, и часто это удобнее чем интерфейс, но абсолютно не всегда.
__________________
Кто к нам с чем для чего - тот у нас того от того. Последний раз редактировалось Dukobpa3; 09.08.2013 в 12:05. |
|
|||||
Et cetera
Регистрация: Sep 2002
Сообщений: 30,784
|
Ну хоть какая-то движуха пошла.
|
Часовой пояс GMT +4, время: 11:05. |
|
« Предыдущая тема | Следующая тема » |
|
|