[Wolsh]

Вы не правы, да.
Во-первых, у меня вообще локальная переменная. Когда функция отработает, вообще никакого bl не будет (у автора не так). Ссылки на шарики как бы не нужны вовсе. Они в дисплейлисте, и никуда не денутся. А привязка данных к ним осуществлена через Справочник. Слушатель же получает ссылку на конкретный шарик из event.currentTarget. Такая вот разгрузка кода.
Про галерею: по тексту все отлично. Не вижу противоречий, каждый занимается своим делом.
Откуда Вы взяли странную мысль что я советую писать все в одном классе? О__о Я вот сейчас снова начал писать паззл, набросал скелет, и у меня 24 класса. И по мере наращивания жирка я собираюсь еще по ним пройтись и разделить кое-где ответственность, так что ещё штук 6-8 от них точно отпочкуются, не говоря уже о куче просто новых, пока не вступивших в игру. Классы длиннее 300 строк считаю тяжелыми и трудными для восприятия.

причем имеет в себе довольно простые функции, которые влияют лишь на мячик?

Изменение положения мячика влияет лишь на мячик? О__о
1) Как изменение положения влияет на мячик? Мячик как-то изменяется?
2) Как изменение положения мячика НЕ влияет на поле, содержащее мячики? Поле с мячиками не меняется?

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

Именно для этого и пишутся, чтобы управлять извне. Именно поэтому как бы вы ни развивали интеллект мячика, чтобы он сам назначал себе координаты в вакууме, в любой момент кто угодно может поставить его "на место", выбросив всю его внутреннюю логику в помойное ведро.
Какое отношение паблик функции имеют к Вашей идее, что мячик должен сам летать куда ему вздумается?

То есть если делать классы, то делать полностью универсальными и редко ими пользоваться? Если футбольное поле, то не класс поле, в нем экземпляр мячика (композиция применяется), экземпляры детей и экземпляр трава, к примеру, а класс поле, а в нем функции "дети, мячик, трава" и в каждой куча кода и куча своих переменных и для управления каждым нужном создавать каждому по 3-4 функции все это внутри класса поля? Разве не от такой системы идет переход в AS3 и ООП?

1)Еще раз — я не знаю, откуда Вы взяли про "функции мячика и мальчика". У автора изначально был класс Ball, как и положено. Это как бы даже не обсуждалось, ибо правильно. Был прекрасный "мячик в себе", делавший то что положено мячику. Ни о каких "функциях", рисующих мячики прямо в Мейне, не было и речи.
2) Переход в AS3 и ООП идет от слепоглухонемого кода на объекте к коду, связывающему объекты в иерархическую систему. Когда мячик меняет состояние поля, подчиненной частью которого он является, это анархический беспредел. Вот манифест этого беспредела:

ball:FootballBall = new FootballBall(ширина и высота поля)

Вы когда-нибудь покупали в магазине "мячик для поля 100 х 210 метров"?
Вы действительно видите в этом какую-то логику?