|
|
|||||
Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
|
Помогите с архитектурой приложения
Всем привет!
Возникла проблема с проектированием иерархии классов в приложении - не могу собрать все воедино. Приложение должно отображать/изменять/добавлять графические объекты (по типу coreldraw). Объекты могут быть векторной фигурой (линия, кривая, замкнутая фигура из линий и кривых), текстом (мультилайн), картинкой. Плюс каждый объект может быть создан из XML-тэга. Форматов XML может быть несколько (т.е. парсеров тоже). Каждый объект может быть сохранен в XML также нескольких форматов. Пока не понимаю как лучше реализовать считывание-сохранение. Что лучше - в каждый класс графического объекта добавить методы по сереализации/десереализации или делать считывание/сохранение отдельными классами? Также хотелось бы гибко реализовать классы так, чтобы в дальнейшем легко было добавлять новые типы графических объектов (группы, маски и т. д.). На данный момент я принял решение объединить представление и данные в классах-наследниках Sprite. Это связано с тем, что Sprite уже содержит кучу полей, общих для всех моих объектов (x, y, width, height, scaleX, scaleY, rotation итд.). Итого, подскажите с: 1) Возможной иерархией классов 2) Как лучше реализовать сереализацию/десереиализацию в/из различных форматов данных? 3) Нормально ли объединять данные с представлением так, как это сделал я? Заранее спасибо. |
|
|||||
1) Как вам удобнее до ближайшего рефакторинга
2) Не знаю, что за паттерн. Но можно использовать интерфейсы и "делать считывание/сохранение отдельными классами" 3) см. пункт 1.
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку. |
|
|||||
Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
|
По 2) Получается, что для каждого класса у меня будет n сереалайзеров (где n-количество форматов)? А где лучше реализовывать саму сереализацию? Мне кажется, что это стоит делать отдельно и не перегружать классы графических объектов. А какое ваше мнение?
|
|
|||||
Эмн. По моему (де)сериалайзеров должно быть по кол-ву форматов. И забирать каждый должен целиком все нарисованное. Пихать в каждый объект описание для каждого сериализатора криво на мой взгляд.
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку. |
|
|||||
Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
|
Согласен. Тогда следующий вопрос: а кто/что будет отвечать за сопоставление класс-сереалайзер? Т.е. где в приложение это будет делаться?
|
|
|||||
Наверно при соответствующих действиях юзера. Выбрал формат, нажал сохранить - создали нужный сериализатор и сохранили. При загрузке смотрим шапку или расширение или расположение звезд ну и создаем десериализатор. Но вариантов много, я самые простые предлагаю.
ЗЫ Первый, кто прибежит в тему со словами "MVC" - можете игнорировать навсегда. Муахаха.
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку. |
|
|||||
Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
|
Ок, спасибо Из ответов понял лишь одно - как удобно, так и надо делать. А будущее покажет. В случае чего - рефакторинг. По поводу MVC - тема по-моему мутная. В разных фреймворках есть разные полезные фичи, но в более-менее большом приложении всегда есть места, где фичи не работают. Здесь я сознательно избегаю разделения Model-View-Container ибо само напрашивается все это объединить. А вот в UI-части буду разделять (формы, окна, диалоги).
|
|
|||||
Контроллер, а не контейнер. Да лучше всего писать, чтобы нравилось самому, ну и работало. А код обычно сам "говорит" - "Папочка, я тут криво получился, поправь!" :о)
Но это если не в команде.
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку. |
|
|||||
Регистрация: Feb 2009
Адрес: WS
Сообщений: 93
|
GBee, да, конечно, Controller
А в чем принципиальная разница при работе в команде. Просто возможно в дальнейшем она (команда) появится |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Может, я чего-то не понимаю, но разве не удобнее иметь один внутренний формат ("RAW", если хотите) и кучку конверторов в другие?
И чем плохо иметь в самих объектах методы, возвращающие их описание? Наследование никто не отменял, а описание круга и описание звезды в любом случае будет содержать совершенно разные свойства. Действительно ли нужно, чтобы сериализатор владел полными знаниями о каждой возможной фигуре и ее свойствах? И при создании новых классов фигур приходилось бы писать не только класс фигуры, но и дополнять сериализатор?
__________________
Reality.getBounds(this); |
Часовой пояс GMT +4, время: 02:13. |
|
« Предыдущая тема | Следующая тема » |
Теги |
архитектура , паттерн , Проектирование |
Опции темы | |
Опции просмотра | |
|
|