Элегантно распарсить клип на элементы и отдать полученное - Страница 3

cleptoman · 21.01.2011, 15:04

если все известно, то зачем там все парсить? вот не пойму я этих манипуляций..бери да клепай где тебе нужно свои стейты и конструируй кнопки.

JackFromChaos · 21.01.2011, 15:06

В общем здесь логичнее не схема Parse->Set->Init, а Parse, Init->Get. Таким образом снижается связность. Менеджер универсален. Он ни о ком ничего не знает. Только данные откуда то о символах получает...
Сам клиент этого дело тоже не особо заворачивается о том, в каком виде и как появляются ресурсы. Для него важно, что он может их получить через единую точку. Связность минимальная. И нет странного места, которое решает какому объекту какой ресурс нужен. Объект сам решает, какой ему нужен ресурс.
Естественно, менеджер может быть универсальным, получать данные самым различным способом(swc, swf,png и т.д.), и при этом использоваться для разных окон, содержать в себе много разных композитов(наборов элементов) и т.д.

КорДум · 21.01.2011, 15:10

Цитата:

если все известно, то зачем там все парсить? вот не пойму я этих манипуляций..бери да клепай где тебе нужно свои стейты и конструируй кнопки.

Тоже верно. Хм, получается, что нужно ссылку на клип передавать во все конструкторы элементов интерфейса, верно? Пожалуй, это будет лучше. Каждый берет то, что ему нужно, необходисмость в парсирующем классе отпадает. Как же я сразу не догадался.

А еще варианты? Может быть найдется еще лучше?

JackFromChaos · 21.01.2011, 15:15

Цитата:

Сообщение от КорДум

А еще варианты? Может быть найдется еще лучше?

От добра-добра не ищут

Лучше вариантов пока в голову не приходит, только хуже...

КорДум · 21.01.2011, 15:36

JackFromChaos, во-во

На самом деле тема для меня очень интересная, уже очень давно думал, как это все лучше организовывать, как только не пробовал, чуть ли не статической ссылкой на клип с графикой. А раньше, когда не знал о способе с getChildByName, вообще каждому элементу присоединял свой класс, скармливал экземпляры этих классов. Как вспомню - бррр. Сейчас просто решил переписать старый плеер под новые знания, вот и задаюсь такими вопросами.

JackFromChaos · 21.01.2011, 15:56

Ну я не знаю, но в данном случае, даже неличие менеджера мне кажется не оправданно. Т.е. к примеру менеджер в 3d он ведь сделан прежде всего для того, что бы управлять ресурсами, оптимизировать загрузку, следить за тем, что бы ресурсы удалялись и т.д. Там это оправданно.
Но Flash другая платформа и задачу тут другая. Нет стоит, имхо, пытаться придумывать универсальные, красивые решения, но совершенно не оправданные с точки зрения данного применения.
Это называется, забивать гвозди микроскопом, имхо.

P.S. К примеру unity 3d, как я узнал недавно, не поддерживает интерфейс, свойства(т.е. getter/setter). Все переменные в классе должны быть публичными и т.д. Но на нем все равно пишут, так как он удобен чем то еще, это специфика платформы. Хотя получается там не применимы многие парадигмы ООП и паттерны..

P.P.S. "Что хорошо для русского, немцу смерть..."

Добавлено через 2 минуты
К слову, композитные текстуры в 3d графики придумали не от хорошей жизни, и не для того, что бы что-то "красиво реализовать"...

КорДум · 21.01.2011, 16:01

А я менеджер и не планировал делать.
Мне нужно только правильно отдавать графику кусочкам логики и все. Мне кажется или вы все на MVC стараетесь переложить?

ps_spectre · 21.01.2011, 16:34

JackFromChaos,

это как так юнити3д не поддерживает свойства? Там полноценный си-шарп, который даже перегрузку операторов поддерживает.

JackFromChaos · 21.01.2011, 16:49

2ps_spectre:
А вот так

На самом деле я деталей не знаю, это у меня жена на нем программирует. Но общая идея такова. Там действительно c#, но при разработке игр, программист должен наследоваться от стандартных компонентов unity, они попадают в редактор unity, и вот уже этот редактор как раз много чего не поддерживает. Такая вот архитектура. Там как бы даже компилятор кажется свой...
Естественно, внешние библиотеки могут пользоваться всем спектром возможностей c#.
Но факт остается фактом, основная разработка для Unity - это скорее сильно кастрированный c#.
Вроде так... Хотя как я уже говорил, с Unity я не работал, и деталей не знаю...

Добавлено через 3 минуты

Цитата:

Сообщение от КорДум

А я менеджер и не планировал делать.
Мне нужно только правильно отдавать графику кусочкам логики и все. Мне кажется или вы все на MVC стараетесь переложить?

Нет менеджера - нет парсера... Вы же о парсере все время говорили...
MVC я подсовывать не пытался...
А еще мне кажется для небольших задач, вроде плеера, один класс из 300 строк, много лучше чем 10 из 50 строк... И потому что в результате строк меньше. Но прежде всего потому, что мы получаем самодостаточный модуль, который легко читается... А втыкнуть в какую то новую(или хорошо забытую старую) может быть куда сложнее..
И если для крупных задач без этого никак, то для мелких - самое то....

ps_spectre · 21.01.2011, 16:55

JackFromChaos, а-а-а, может и так, теперь учту. (з.ы. я сам только хелловорлд в юнити глянул и пока сам могу заблуждаться, все таки мы за флеш ))

сорри за оффтоп