[Wolsh]

ОК.
Сейчас речь пойдет немного не о флэш. О проектировании как самостоятельной дисциплине))
Вот представьте, что Вам на день рожденья подарили новый футбольный мячик.
Вы позвонили двум-трем друзьям и понеслись во двор гонять футбол.
Но, как часто бывает в фильмах ужасов, мячик оказался не простым.
Какой-то злой гений, доктор Девелопер, запихал в него устройство с искусственным интеллектом, и теперь мячик сам решает, куда ему лететь и в какой точке футбольного поля останавливаться.
Самое противное в том, что мячик делает это по каким-то своим правилам, а не правилам Футбольной Лиги, и даже не по вашим с друзьями правилам.
Теперь представим, что фильм приближается к хеппи-энду, и с помощью одноклассника-ботана вам удалось взломать мячик и Вы можете перепрограммировать его правила. Вопрос на засыпку: какова вероятность того, что Вы выберите отключить мячику всякое, любое, интеллектуальное поведение, и только тогда сможете наслаждаться игрой, когда он просто полетит туда, куда Вы его пнете?
В чём мораль?
Любой объект, являющийся частью системы, идеален тогда, когда не диктует своих правил объектам системы выше по иерархии. Объект должен заниматься только собой и своими подчиненными (своими частями). Футбольное поле не содержится в мячике. Контейнер не содержится в ребенке. Положение мячика это положение на поле. У самого мячика никакого положения нет. Есть положение лоскутов и ниппеля, и положение логотипа на мячике. Это — область ответственности мячика. Этого — ни поле, ни судья, ни голкипер не могут изменить в мячике. Это его личное дело, его личная ответственность, его составляющие в его системе координат. А вот положение мячика может изменить и голкипер, и защитник, и даже чирлидерша в розовых гольфах. Какой бы икс-игрек он там себе ни пыжился назначить, любой котенок без труда назначит ему другой одним касанием. Потому что у мячика есть место в иерархии и есть положение в системе координат его контейнера (стараюсь избежать слова "родителя", хотя обычно так и бывает). Управлять мячиком должен тот, кто его создал с известной только ему (не мячику!) целью, для решения своих (не мячика!) задач.
В данном конкретном случае у автора все было более-менее логично и соответствовало ООП. Конечно, можно расширять проект дальше, но — расширять, а не закапывать вглубь. Рано или поздно будет написан класс BallContainer или GameScreen. А кнопки и статусы будут вынесены в HUD. И еще много чего появится. Но если шарики будут летать по своим собственным делам, а кнопки будут сами решать, какие функции в главном классе им вызывать, это будет шапито, а не приложение, написанное программистом.