|
|
|||||
Цитата:
Я бы не стал в классы что-то добавлять. Просто один класс Сериализатор/Десеарелизатор, с методами serialize(наборOбъектов):XML deserialize(xml:XML):Набор объектов А в методах - разбор свичами. Есть, конечно, вариант без свичей: - заносим в список набор сериализаторов и одновременно десериализаторов на каждый тип объекта - регистрируем в словарике сериализатор на тип объекта - при сериализации берём из словарика нужный сериализатор - при десериализации перебираем все десериализаторы и вызываем метод ПодходитЛиЭтотСериализатор():Boolean, если подходит вызываем метод Десериализовать():ТипОбъекта Но ни разу такого не потребовалось. Обычно, при появлении нового типа, проще в 2 свича добавить по варианту - оно же в одном месте, а не по всему коду разбросано. Цитата:
- предполагается, что в любой момент времени есть возможность (т.е. вьюшка не ссылается на объект, который нужно убрать со сцены) и не жалко держать всю эту графику в памяти (проблему можно обойти: вместо класса "графика + данные" сделать класс с двумя полями: "графика" и "данные", и убирать графику из объекта, когда она не нужна) - не требуется несколько представлений изображений (не фатальная проблема - здесь можно выделить "главный вид", который будет одновременно моделью, а остальные всякие отображения будут им пользоваться) Короче, должно прокатить для вашего случая 2 Wolsh Цитата:
Но это может и не потребоваться, меня больше другой вопрос беспокоит: Вот Вы сериализовали данные, повызывав методы у объектов А десеариализовывать как? Вот есть голые данные, у какого объекта вызывать метод десериализации? Тут либо свитч (а значит надо лазить в логику главного парсера при добавлении новых элементов) Либо регистр со списком парсеров (что во многих случаях перебор и архитектурная астронавтика) Или есть другой способ? Последний раз редактировалось expl; 09.11.2012 в 16:25. |
|
|||||
Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
|
Expl, спасибо за совет.
Wolsh, вот в этом-то и раздумья С одной стороны не хочется перегружать основные классы графических объектов. С другой - это логично. И, кстати, отличная идея по поводу конвертации, но по-моему при больших объемах данных приложение будет тормозить при переконвертации. Выходит, что чтобы сохранить, к примеру, в SVG мне нужно сначала сохранить во внутренний XML, а потом его конвертить в SVG (другой XML). Может выйти ресурсоемко. Как думаете? Я, все же, склоняюсь к отдельному сереалайзеру со switch-ами. По поводу разницы между кругом и звездой - тут есть два подхода. Первый - ваш - разница есть и пользователь может менять специфические параметры после рисования (например радиус круга или число лучей звезды). Второй - и я его решил использовать - разницы никакой нет. Ведь по сути каждая плоская фигура - это набор линий и кривых (я использую прямые и кривые Безье второго порядка). А определять что конкретно будет нарисовано будут диалоги, привязанные к панели инструментов приложения. Т.е. после рисования все фигуры одинаковы - это объекты некоего класса Path. Пользователь сможет двигать точки, управлять точками привязки кривых. Как-то так. Есть еще один вопрос: каждый тип графических объектов будет иметь свою панель свойств. Где в приложении лучше хранить соответствие класс/интефейс графического объекта -> окошко свойств? Аналогично сереалайзерам? Добавлено через 14 минут Цитата:
Есть еще одна проблема: возможно придется размещать графику на очень больших экранных областях для эмуляции печати на больших площадях. Насколько я знаю, размер контейнера ограничен 8191 пикселями. Есть ли у кого-нибудь идеи как справиться с большими размерами? Придется изобретать подобие GoogleMaps ? |
|
|||||
Цитата:
Если уж там код будет дублироваться - то можно сделать промежуточный "метаформат" в виде другого набора объектов, промежуточный xml как-бы здесь ничего не упростит. Цитата:
Но даже если придется, свитчи я бы здесь не городил. Добавлено через 10 минут Цитата:
Да и Sprite не обязательно на сцену добавлять, чтобы он существовал. Добавлено через 19 минут Цитата:
- при создании графики и присваивании её к полю объекта нужно её обновить. - плюс всякие graphic != null по всему коду. Короче if-фов будет много. Вобщем паттерн Observer/EventDispatcher не от нечего делать придумали. Но, может, будет проще и без диспетчеризации - попробуйте сначала изменять объект с данными и графикой как единое целое. Последний раз редактировалось expl; 09.11.2012 в 16:48. |
|
|||||
Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
|
Цитата:
А вообще, мне удивительно, что вы легко обходите заученные правила ООП . Причем без ущерба для приложения. Я почему-то не решаюсь с легкой руки связывать, добавлять поля, рефакторить итд. В целом, спасибо, буду анализировать. Пока что - разрыв мозга - слишком много хочу объять и учесть. |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Чето вы меня совсем запутали. То у Вас куча классов объектов, то любой объект это только путь для отрисовки + настройки графикса (наверное). Как бы разница существенная, если все, что должен отдать объект для сериализации, абсолютно единообразно для любого объекта. Тогда и вопросов нет. А замечание про единый формат относилось к вашей идее пихать все нужные сериализаторы в классы объектов. Если "формат" всех объектов един, то естественно внутреннего представления не нужно, любой сериализатор можно писать, опираясь на этот "формат" (путь и цвета-альфы и чего там еще). Как бы, мое представление о сериализации основано на разработке GUI с контролами совершенно разных классов. Здесь этот подход.. не подходит))
__________________
Reality.getBounds(this); |
|
|||||
Цитата:
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку. |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Вот и я так понял. Отсюда и RAW, чтобы конверторы можно было писать под любые форматы в любое время, не трогая остальной код.
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
|
Цитата:
Цитата:
|
|
|||||
Цитата:
И при сохранении и восстановлении будет сохраняться и восстанавливаться разный набор значений для каждого типа объекта. |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Цитата:
А после десериализации ваша программа будет иметь только Путь, набор соединенных точек? И редактировать полигон как Полигон уже будет невозможно? Все "диалоги" будут только до момента сохранения?
__________________
Reality.getBounds(this); |
Часовой пояс GMT +4, время: 15:49. |
|
« Предыдущая тема | Следующая тема » |
Теги |
архитектура , паттерн , Проектирование |
Опции темы | |
Опции просмотра | |
|
|