Правильное ООП
 

Доброго времени суток вам уважаемые господа флешеры.

Очень тут взволновал меня один вопрос.

Допустим у нас есть несколько объектов класса Ball. Эти объекты должны двигаться каждый по своей траектории, обусловленной различными внешними факторами: сила ветра, начальная скорость. И вот здесь возникает вопрос: как правильно с точки зрения ООП и практичности кода реализовать движение этих объектов.

Вариант 1: Сохранить в прототипе класса Ball метод move и вызывать его из каждого объекта.

Вариант 2: Сделать глобальный метод среды, который будет определять кто из объектов должен двигаться и в зависимости от этого передвигать их.

Господа-профессионалы, поделитесь опытом.

Вариант 1. С точки зрения ООП
Вариант 2. Практичней из-за особенностей самого флэша :) (особенно если шариков много)

Господа, неужто только один человек сталкивался с подобным выбором?
Отчего стоит исходить при структурировании кода?

оба варианта правильные, просто во втором варианте ты создаешь еще твинМанэджер, а в инстансы классов регистриуешь в нем при надобности движения.

Так собственно работают почти все программные твины, тогоже роберта принера и макромедийные

что лучше решать тебе, так как первый вариант может достаточно тормозить во флэше

Ну сам-то подумай...
Для кого делают классы? Для обычных пользователей. Чтобы им было удобнее управлять объектом! Как здорово:
Math.sin(0) - и посчитался синус! Не нужно ничего высчитывать ручками!
Array.unshift() - и не нужно заморачиваться с индексами!
MovieClipLoader.onLoadProgress - и забудьте про рутину с загрузкой клипов!
...
---
Канэчно, при использовании классов появляются накладные расходы ресурсов! Всякие конструкторы, контекст обращения к объекту... Поэтому, если ты оптимизируешь код - пиши внешнюю процедуру управления шариками, если ориентируешься на пользователя - юзай класс!
Это не вопрос к профи, это основы программирования.
Как думаешь, почему все рассуждают о том, что если программировать DOOM3 на ассемблере, то достаточно было бы 386 компа 80)
Вопрос ресурсов: сколько это времени займет. Думаю, что если начать использовать ассемблер с жестким архитектурным контролем кода, то в этот дум и наши правнуки бы не успели поиграть! А деньги разработчики хотят уже сегодня... Утрирую, но суть от этого не меняется.

Хотя оптимизация оптимизации рознь. Стоит ли оптимизировать код, если у тебя 3 шарика? Которые будут прыгать по ветру в течении 3-х секунд? И вообще, зачем для этого нужны классы! Отдаем дань моде? 80)
Сделай простой мувик с интерфейсным управлением: мувик с шариком с набором функций:
поменять скорость()
поменять координаты()
поменять еще чего-нибудь()
...

to kost@: шарики я привел лишь в качестве примера. Задам вопрос более правильно: "Есть игра. В игре по полю бегают несколько ботов. Боты бегают, наталкиваются на различные препятствия, меняют направление движения. Так, блин, как правильно, удобнее и целесообразнее организовать движение этих объектов? И от каких факторов зависит выбор варианта?"

А-а, тут все серъезней... Я бы использовал классы. Меньше потом отвлекаешься на программную логику. Если ошибешься в просчетах - быстрее исправить: переписал один соответствующий метод...
На классах - удобнее. Факт!

Через классы