[Wolsh]

Это хорошо.
Вот у Вас допустим есть класс БильярдныйСтол, описывающий размеры стола и положение луз, трение поверхности, ну и если это не MVC, то конечно рисующий сам столик.
Есть класс БильярдныйШар, описывающий шарик, его размеры и возможно физические параметры (трение и массу для инерции), и умеющий рисовать красивый шарик с бликами и цифрами, заданного цвета.
И есть класс, управляющий физикой шариков на столе. Этот класс принимает как параметры БильярдныйСтол и БильярдныйШар.
И наконец есть судейский класс, интерпретирующий происходящее на столе в соответствии с принятыми Правилами игры.
Это — обычное решение в стиле ООП. Начиная с этого момента Вы можете свободно заменять классы стола и шариков, как угодно. Если надо подкорректировать физику, Вам достаточно покопаться в классе-менеджере физики. И вы можете менять Правила судейства для разных игр на бильярде. Это ключевые концепции проектирования в ООП: универсальность, заменяемость, расширяемость, разделение ответственности.
Вы можете включить в игру несколько комнат с разными красивыми столами. Разные стили шариков. Разные правила игры. При этом стол будет описывать только стол. Шарик — только шарик. Вам не нужно будет писать всю физику системы в каждом классе шариков или столов. Нужно только описать характерные свойства именно данного класса шарика, данного класса стола. И в будущем, если вы захотите написать новый бильярд, Вы сможете воспользоваться этими же классами "как есть".
А теперь представьте, что в эту систему кинули шарик, который сам все решает....

Еще один пример.. Вам в программе потребовалась кнопка. Допустим это простой СимплБаттон, не важно. Вы нашли где-то класс, рисующий красивые кнопочки для Состояний кнопки, принимая цвета, размеры, текст лейбла и т.п. Вы собрали из них красивейшую кнопку, но счастье длилось не долго: оказывается, создатель этого класса запихал в него собственное поведение при мышиных событиях и переопределил сеттеры размеров, альфы, visible и до кучи mouseEnabled))))))) Это умозрительный эксперимент, мало кто до такого додумается — я нарочно утрирую, чтобы показать непрактичность такого подхода. Всё, что требовалось от состояния — быть красивым и визуально настраиваемым. В этом вся его ответственность. А его поведение должно настраиваться системой, в которой его решили использовать — в данном случае кнопкой.