[MINASTIS]

Вообще, вы правы.
Я с какого-то перепуга ошибочно решил, что все делается в одном цикле, и создание, и привязка к движениям и т.д.
Конечно я логики в этом не вижу особой, потому что в случае создания мячика с определенными координатами поля, чтобы он не мог за него вылететь, к примеру в игре в бильярд (в футболе то он может вылететь, это я погорячился, упомянув футбол, а так происходит упрощение игры, чтобы мячик не мог улететь за пределы поля), класс мячика становится не универсальным и очень специализированным.

Даже если в нем прописать всю физику, то она не будет взаимодействовать с пределами поля\стола, он просто к примеру будет останавливаться и не идти дальше.

Для этого надо делать дополнительный класс физического тела (опять же, не разбираюсь в кодинге физики, говорю на вскидку), с которым мячик может взаимодействовать и из экземпляров этого класса делать стенки стола\поля.

С мячиком и полем, это как startDrag()
Только вместо объекта для перетаскивания мячик а вместо области для "в пределах которой можно объект таскать" - ширина и высота поля, чтобы как ни таскайся\двигайся мячик - он не уйдет за его пределы.
Это простой пример ограничения движения. Т.е. поле может рисоваться само и в экземпляр мячика просто кидает уже после своей отрисовки свои же ширину и высоту.
По сути поле диктует мячику, в какой области он может двигаться.

И еще насчет непонимания, как оказалось, я понятия не имею про dictionary и что он делает, поэтому для меня весь код показался странным)

Т.е. все мои вопросы и претензии изначально беспочвенны. Насчет структуры, это да, я считаю, что твины для движения и любые листенеры для взаимодействия с мышкой должны быть в классе ball, т.к. так проще, на мой взгляд. Внутри.
Т.е. создавать не класс ball, который просто рисует шарик, а класс, к примеру, AwayBall. Это часто делает надобность писать кучу других классов для других шариков, если таковые имеются, но что поделать. Зато следить за огромной структурой приложения, если она такой будет, будет удобней.