Здравствуйте, Нomunculus, Вы писали:

Н>Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.

ооп-шно не надо. вообще тащить везде ооп это какое-то старперство из 90х.

не приведено никаких требований по симуляции — что должно быть результатом симуляции?
в первую очередь надо решить задачу математически, отталкиваясь от того, какие данные нужны на выходе.
выделить сущности (данные, не объекты!) и взаимоотношения между ними (операции).
а потом прикинуть как это все удобнее всего накинуть на тот ооп-язык, который есть. но удобнее для решения задачи, а не для удовлетворения "ооп-шности".

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

Здравствуйте, Нomunculus, Вы писали:
Н>А объект этот — тряпка.
Н>Вопрос — КУДА СУНУТЬ ВЕТЕР???
Ветер это "контроллер", он модифицирует внутреннее состояние "модели" тряпка. Чтобы инкапсулировать код "ветра" на все модели надо задать интерфейс "модель качаемая ветром", но это наверное будет нереально, т.к. "тряпки" и "не тряпки" качаются сильно по разному и контроллер "ветер" получит для каждой существенно разной модели свою реализацию метода. Для метода "ветра качающего тряпку" надо задать интерфейс доступа к внутреннему состоянию "модель тряпки качаемая ветром".
===