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

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

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

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

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

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

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

По всему остальному да, а вот по примеру -- нет (или переубедите, пожалуйста)
Для меня ООП это в основном не об инстансов объектов и о том, как они обмениваются, а о том, что "код рядом с данным", т.е. на самом деле "данных" нет, это все "инкапсулировано".И вот тут

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

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

По всему остальному да, а вот по примеру -- нет (или переубедите, пожалуйста)
Для меня ООП это в основном не об инстансов объектов и о том, как они обмениваются, а о том, что "код рядом с данным", т.е. на самом деле "данных" нет, это все "инкапсулировано".
И вот тут между takeDamege(entity) и entity.takeDamege() разница приципиальная. Я не хочу сказать, что takeDamege(entity) это плохо, просто разница есть, и если в моей софтине "принимать повреждения" -- это "в природе" самого объекта (а не просто частный сценарий взаиможействия с ним), то я предпочту entity.takeDamege()