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

V>В геймдеве свои специфические подходы: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system
V>Там ООП не на первом месте, главное 60 раз и больше за секунду всё отработать (и если надо — тени отключить).

Entity-Component-System это конкретный подход, можно сказать архитектурный паттерн и он нисколько не противоречит ООП.

ООП нужно не для наследования-инкапсуляции-полиморфизма, а для управления сложностью решения. Т.е. структурирование решения.
Как только ты решил задачу, её нужно перевести в код. Вот здесь и начинает работать ООП. А Entity-Component-System это уже конкретный вариант дизайна.

Собственно именно в геймдеве прижилось чистейшее ООП — объекты состоят из объектов, взаимодействуют с другими объектами посредством сообщений и тд. Частный случай взаимодействия — управление, так же делается посредством сообщений.

Отсюда ясно, что привязаны методы к самому объекту или не привязаны это для ООП дело десятое, как ни странно. То есть, takeDamege(entity) и entity.takeDamege() абсолютно эквивалентны.