Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 09.11.2012, 16:05
expl вне форума Посмотреть профиль Отправить личное сообщение для expl Найти все сообщения от expl
  № 11  
Ответить с цитированием
expl

блогер
Регистрация: Feb 2006
Сообщений: 1,474
Записей в блоге: 3
Цитата:
Пока не понимаю как лучше реализовать считывание-сохранение. Что лучше - в каждый класс графического объекта добавить методы по сереализации/десереализации или делать считывание/сохранение отдельными классами?
На сериализации это даст какую-то гибкость, но десериализовывать всё равно придется свичами.
Я бы не стал в классы что-то добавлять.
Просто один класс Сериализатор/Десеарелизатор, с методами
serialize(наборOбъектов):XML
deserialize(xml:XML):Набор объектов
А в методах - разбор свичами.

Есть, конечно, вариант без свичей:
- заносим в список набор сериализаторов и одновременно десериализаторов на каждый тип объекта
- регистрируем в словарике сериализатор на тип объекта
- при сериализации берём из словарика нужный сериализатор
- при десериализации перебираем все десериализаторы и вызываем метод ПодходитЛиЭтотСериализатор():Boolean, если подходит вызываем метод Десериализовать():ТипОбъекта

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

Цитата:
На данный момент я принял решение объединить представление и данные в классах-наследниках Sprite
Это хорошее решение, если:
- предполагается, что в любой момент времени есть возможность (т.е. вьюшка не ссылается на объект, который нужно убрать со сцены) и не жалко держать всю эту графику в памяти
(проблему можно обойти: вместо класса "графика + данные" сделать класс с двумя полями: "графика" и "данные", и убирать графику из объекта, когда она не нужна)
- не требуется несколько представлений изображений
(не фатальная проблема - здесь можно выделить "главный вид", который будет одновременно моделью, а остальные всякие отображения будут им пользоваться)

Короче, должно прокатить для вашего случая

2 Wolsh
Цитата:
И чем плохо иметь в самих объектах методы, возвращающие их описание?
Ничем, пока в другой формат не придётся переводить.
Но это может и не потребоваться, меня больше другой вопрос беспокоит:
Вот Вы сериализовали данные, повызывав методы у объектов
А десеариализовывать как? Вот есть голые данные, у какого объекта вызывать метод десериализации?

Тут либо свитч (а значит надо лазить в логику главного парсера при добавлении новых элементов)
Либо регистр со списком парсеров (что во многих случаях перебор и архитектурная астронавтика)
Или есть другой способ?


Последний раз редактировалось expl; 09.11.2012 в 16:25.
Старый 09.11.2012, 16:11
Vasyaga вне форума Посмотреть профиль Отправить личное сообщение для Vasyaga Найти все сообщения от Vasyaga
  № 12  
Ответить с цитированием
Vasyaga

Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
Expl, спасибо за совет.

Wolsh, вот в этом-то и раздумья С одной стороны не хочется перегружать основные классы графических объектов. С другой - это логично. И, кстати, отличная идея по поводу конвертации, но по-моему при больших объемах данных приложение будет тормозить при переконвертации. Выходит, что чтобы сохранить, к примеру, в SVG мне нужно сначала сохранить во внутренний XML, а потом его конвертить в SVG (другой XML). Может выйти ресурсоемко. Как думаете? Я, все же, склоняюсь к отдельному сереалайзеру со switch-ами.
По поводу разницы между кругом и звездой - тут есть два подхода. Первый - ваш - разница есть и пользователь может менять специфические параметры после рисования (например радиус круга или число лучей звезды). Второй - и я его решил использовать - разницы никакой нет. Ведь по сути каждая плоская фигура - это набор линий и кривых (я использую прямые и кривые Безье второго порядка). А определять что конкретно будет нарисовано будут диалоги, привязанные к панели инструментов приложения. Т.е. после рисования все фигуры одинаковы - это объекты некоего класса Path. Пользователь сможет двигать точки, управлять точками привязки кривых. Как-то так.

Есть еще один вопрос: каждый тип графических объектов будет иметь свою панель свойств. Где в приложении лучше хранить соответствие класс/интефейс графического объекта -> окошко свойств? Аналогично сереалайзерам?

Добавлено через 14 минут
Цитата:
Это хорошее решение, если:
- предполагается, что в любой момент времени есть возможность (т.е. вьюшка не ссылается на объект, который нужно убрать со сцены) и не жалко держать всю эту графику в памяти
- не требуется несколько представлений изображений
(но последнее не фатальная проблема - здесь можно выделить "главный вид", который будет одновременно моделью, а остальные всякие отображения будут им пользоваться)
Возможно, что иногда будет нужно хранить в памяти невидимые объекты. Например, при Copy/Cut/Paste. Еще думаю, что возможно есть смысл прорисовывать только объекты, которые входят в видимую рабочую область. Хотя не уверен, ведь в моем случае они будут всегда храниться в памяти.

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

Старый 09.11.2012, 16:26
expl вне форума Посмотреть профиль Отправить личное сообщение для expl Найти все сообщения от expl
  № 13  
Ответить с цитированием
expl

блогер
Регистрация: Feb 2006
Сообщений: 1,474
Записей в блоге: 3
Цитата:
Выходит, что чтобы сохранить, к примеру, в SVG мне нужно сначала сохранить во внутренний XML, а потом его конвертить в SVG (другой XML)
Да ну, это глупо. Набор объектов (пусть визуальных) - это уже внутренний формат.
Если уж там код будет дублироваться - то можно сделать промежуточный "метаформат" в виде другого набора объектов, промежуточный xml как-бы здесь ничего не упростит.

Цитата:
Есть еще один вопрос: каждый тип графических объектов будет иметь свою панель свойств. Где в приложении лучше хранить соответствие класс/интефейс графического объекта -> окошко свойств? Аналогично сереалайзерам?
На объект повесьте. Будет удобно, пока не придется показывать панельки не только в зависимости от объекта, но и от ситуации.
Но даже если придется, свитчи я бы здесь не городил.

Добавлено через 10 минут
Цитата:
Возможно, что иногда будет нужно хранить в памяти невидимые объекты. Например, при Copy/Cut/Paste. Еще думаю, что возможно есть смысл прорисовывать только объекты, которые входят в видимую рабочую область. Хотя не уверен, ведь в моем случае они будут всегда храниться в памяти.
Я там написал уже про решение - делаем объект с 2-мя полями: данные и графика и его везде используем вместо старого.
Да и Sprite не обязательно на сцену добавлять, чтобы он существовал.

Добавлено через 19 минут
Цитата:
Я там написал уже про решение - делаем объект с 2-мя полями: данные и графика и его везде используем вместо старого.
Забыл: при таком решении появляется другая проблема:
- при создании графики и присваивании её к полю объекта нужно её обновить.
- плюс всякие graphic != null по всему коду. Короче if-фов будет много.
Вобщем паттерн Observer/EventDispatcher не от нечего делать придумали.
Но, может, будет проще и без диспетчеризации - попробуйте сначала изменять объект с данными и графикой как единое целое.


Последний раз редактировалось expl; 09.11.2012 в 16:48.
Старый 09.11.2012, 16:50
Vasyaga вне форума Посмотреть профиль Отправить личное сообщение для Vasyaga Найти все сообщения от Vasyaga
  № 14  
Ответить с цитированием
Vasyaga

Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
Цитата:
Забыл: при таком решении появляется другая проблема:
- при создании графики и присваивании её к полю объекта нужно её обновить.
- плюс всякие graphic != null по всему коду. Короче if-фов будет много.
Вобщем паттерн Observer/EventDispatcher не от нечего делать придумали.
Ну да, или биндить во флексе.
А вообще, мне удивительно, что вы легко обходите заученные правила ООП . Причем без ущерба для приложения. Я почему-то не решаюсь с легкой руки связывать, добавлять поля, рефакторить итд. В целом, спасибо, буду анализировать. Пока что - разрыв мозга - слишком много хочу объять и учесть.

Старый 09.11.2012, 16:52
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 15  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Чето вы меня совсем запутали. То у Вас куча классов объектов, то любой объект это только путь для отрисовки + настройки графикса (наверное). Как бы разница существенная, если все, что должен отдать объект для сериализации, абсолютно единообразно для любого объекта. Тогда и вопросов нет. А замечание про единый формат относилось к вашей идее пихать все нужные сериализаторы в классы объектов. Если "формат" всех объектов един, то естественно внутреннего представления не нужно, любой сериализатор можно писать, опираясь на этот "формат" (путь и цвета-альфы и чего там еще). Как бы, мое представление о сериализации основано на разработке GUI с контролами совершенно разных классов. Здесь этот подход.. не подходит))
__________________
Reality.getBounds(this);

Старый 09.11.2012, 16:53
GBee вне форума Посмотреть профиль Отправить личное сообщение для GBee Найти все сообщения от GBee
  № 16  
Ответить с цитированием
GBee
 
Аватар для GBee

Регистрация: Jan 2009
Сообщений: 3,067
Записей в блоге: 3
Отправить сообщение для GBee с помощью Skype™
Цитата:
И чем плохо иметь в самих объектах методы, возвращающие их описание?
Я имел в виду описание под каждый сериализатор. Я так понял, хочет ТС.
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку.

Старый 09.11.2012, 17:00
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 17  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Вот и я так понял. Отсюда и RAW, чтобы конверторы можно было писать под любые форматы в любое время, не трогая остальной код.
__________________
Reality.getBounds(this);

Старый 09.11.2012, 17:02
Vasyaga вне форума Посмотреть профиль Отправить личное сообщение для Vasyaga Найти все сообщения от Vasyaga
  № 18  
Ответить с цитированием
Vasyaga

Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
Цитата:
Чето вы меня совсем запутали. То у Вас куча классов объектов, то любой объект это только путь для отрисовки + настройки графикса (наверное). Как бы разница существенная, если все, что должен отдать объект для сериализации, абсолютно единообразно для любого объекта. Тогда и вопросов нет. А замечание про единый формат относилось к вашей идее пихать все нужные сериализаторы в классы объектов. Если "формат" всех объектов един, то естественно внутреннего представления не нужно, любой сериализатор можно писать, опираясь на этот "формат" (путь и цвета-альфы и чего там еще). Как бы, мое представление о сериализации основано на разработке GUI с контролами совершенно разных классов. Здесь этот подход.. не подходит))
Нет, кроме фигур будут еще тексты разного рода и формата, а также картинки, а в будущем - группы и маски.

Цитата:
Я имел в виду описание под каждый сериализатор. Я так понял, хочет ТС.
Совершенно верно, у меня будет два формата десереализатора и два формата сереализатора.

Старый 09.11.2012, 17:04
expl вне форума Посмотреть профиль Отправить личное сообщение для expl Найти все сообщения от expl
  № 19  
Ответить с цитированием
expl

блогер
Регистрация: Feb 2006
Сообщений: 1,474
Записей в блоге: 3
Цитата:
Если "формат" всех объектов един, то естественно внутреннего представления не нужно, любой сериализатор можно писать, опираясь на этот "формат" (путь и цвета-альфы и чего там еще). Как бы, мое представление о сериализации основано на разработке GUI с контролами совершенно разных классов. Здесь этот подход.. не подходит))
Я так понял, существует куча разнотипных объектов, отнаследованных от одного базового класса.
И при сохранении и восстановлении будет сохраняться и восстанавливаться разный набор значений для каждого типа объекта.

Старый 09.11.2012, 20:19
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 20  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Цитата:
Второй - и я его решил использовать - разницы никакой нет. Ведь по сути каждая плоская фигура - это набор линий и кривых (я использую прямые и кривые Безье второго порядка). А определять что конкретно будет нарисовано будут диалоги, привязанные к панели инструментов приложения. Т.е. после рисования все фигуры одинаковы - это объекты некоего класса Path. Пользователь сможет двигать точки, управлять точками привязки кривых.
Как бы вот. Никакой "кучи" не видно. Насколько я понимаю, примитивов нет. И вот мне ну никак не понятно.. вот если бы я делал графический редактор (не раз порывался), у меня непременно были бы примитивы. И вот допустим пользователь использует примитив, у него есть панелька с настройками, скажем такой вот правильный полигон
PolygonPen.swf   (21.7 Кб)

А после десериализации ваша программа будет иметь только Путь, набор соединенных точек?
И редактировать полигон как Полигон уже будет невозможно?
Все "диалоги" будут только до момента сохранения?
Вложения
Тип файла: swf PolygonPen.swf (21.7 Кб, 111 просмотров)
__________________
Reality.getBounds(this);

Создать новую тему Ответ Часовой пояс GMT +4, время: 15:49.
Быстрый переход
  « Предыдущая тема | Следующая тема »  

Теги
архитектура , паттерн , Проектирование
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 15:49.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.