![]() |
У меня конечно изначально была идея взять за основу шаблон состояние:
Код AS3:
Код AS3:
Действия состояний: Код AS3:
Непосредственно сами состояния: Код AS3:
Описание состояний: Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
|
1. Реализовывать наблюдатель не нужно - используйте нативные для AS3 события.
2. Я бы сделал MVC, (не то, что оно тут уместно, но у меня всегда MVC получается :) |
Цитата:
Дальше по коду. Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Цитата:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Ваши парсеры не валидируют структуру. Т.е. у вас все поля опциональные (и весь остальной код к этому должен быть готов). P.S. Я не помню, что у вас в той библиотеке происходит при двух параллельных запросах (т.е. второй приходит тогда, когда первый еще не отработал). Вроде бы что-то нехорошее... |
Цитата:
Модель - занимается состоянием, значит строим на основе: Наблюдатель или Состояние Представление - отображает состояние, значит строим на основе: Компановщик или Декоратор Контроллер - обрабатывает действия, значит строим на основе: Наблюдатель или Состояние конечно я могу и ошибаться Цитата:
|
Цитата:
1. Понять, чем вообще занимается приложение 2. Понять, как будет устроен обмен с сервером. Подсказка - обмен может быть устроен неоднородно, может быть несколько различных типов обмена. 3. Детализировать и формализовать (не обязательно слишком усердствовать) требования к API (как то обработка ошибок, мониторинг процесса загрузки). 4. Определиться, что может измениться в ближайшее время (неделя, месяц, три месяца, год). 5. Определиться, что вряд ли будет меняться в ближайшее время (месяц, три месяца, год). 6. Сделать draft API. Типичные действия пользователей библиотеки (на момент разработки) должны делаться легко и просто. 90% действий в идеале должны выполняться за 1-3 строчки кода. 1 строчка - идеал, но не всегда достижима. Все зависит от того, насколько "общей" получается задача. 7. Реализовать этот внешний API. О внутренностях можно не очень заботится. При необходимости их можно будет переписать или отрефакторить. Главное, что внешний API будет удобен. 8. На практике отследить, что API действительно удобен. При необходимости исправить API. Вот примерно в том, что выше, и состоит работа разработчика ПО. А код - это побочный продукт разработки. Через несколько подобных реализаций вы начнете видеть похожие элементы в них и получите несколько удобных кубиков, из которых можно что-то собрать. Только вот "кубики" слишком универсальными все равно не поулчатся. У разных приложений разные требования, разные сценарии работы и т.п. Поэтому процентов 50 вы, может, на кубиках наберете (упрощение API URLLoader'а, какие-то совсем базовые вещи). А остальные 50% все равно придется реализовывать под конкретный проект. То же сетевое API во флеш достаточно высокоуровневое, до API уровня приложения там не так много можно добавить. |
2 yasha005: Это тот случай, когда надо использовать свичи и не плодить классов.
|
вы тратите слишком много времени на ерунду (комментирование закрывающих скобок это вообще фаталити)... пишите легкий для восприятия код KISS - keep it simple stupid. Правильно декомпозируйте код, давайте методам понятные имена и всё у вас получится.
|
Цитата:
2. Разумеется обмен с сервеном будет неоднородным, единственное что объединяет обмен данных между собой, это то что они в XML формате 3. Обработка ошибок, мониторинг процесса передачи данных, парсинг данных после их принятия с сервера из XML в объект, формирование данных для отправки их на сервер из объекта в XML 4. Возможно, добавятся новые XML объекты (как приёма, так и передачи данных) 5. Возможно, изменятся существующие XML объекты 6. Вот с этим сложнее, почему-то на практике получается, что я хоть и отправляю одни какие-либо данные ввиде объекта-параметра методу нужного класса. В итоге получается что в этот объект приходится запихивать кучу функций, таким образом не получается уложиться в 1-3 строчки. 7. Если это построение структуры, то беру за основу либо шаблон Компановщик, либо Декоратор; если это какое-либо поведение, то беру за основу либо шаблон Наблюдатель, либо Состояние 8. В том плане что шаблон проектировани удобен - тут сомнений нет, другое дело, что он не всегда в тему может оказаться. За совет, спасибо Добавлено через 6 минут Цитата:
Добавлено через 9 минут Цитата:
|
И самое главное!
Начните с использования конвенций наименований, принятых в AS3. |
Ну время сборки это не принципиально. Оно еще и зависит от используемых инструментов. Да и штатный компилятор параллелить не умеет вроде бы сборку, так что задействовано одно ядро.
Неоднородности - это не только форматы данных. Это еще и схемы обмена. Либо запрос-ответ, либо асинхронный обмен сообщениями. Это тоже влияет на API (очевидно, что API для синхронного и асинхронного обмена совершенно различны). Обработка ошибок вполне может быть на разных уровнях. Очевидно, что на "транспортном" уровне корректно ее обработать (вывести сообщение, например) сложно. Это автоматически дает несколько различных уровней со своим API. Соответственно, различные клиенты используют разные уровни API (обычно - только высокоуровневые). Цитата:
Цитата:
Цитата:
|
| Часовой пояс GMT +4, время: 17:27. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.