Что уже написал, до того, как такая мысль возникла? Покажешь?

А вот смотри, в примере с кирпичиком и очками, у меня такой вопрос. Почему сколько дают очков за разрушение, должно храниться именно в кирпичике? Это гибко и удобно, не спорю. Но почему владением занимается именно сам объект?

Тут спорно - "сущность" кирпичика не обязана быть объектом в системе, это может быть просто идентификатор а за очки может отвечать другой объект. Попытка моделировать систему сущностями часто приводит к пухнущим объектам. Это скорее всего идёт от мега упрощённой интерпретации "модели реального мира".

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

Так же "ооп это плохо" будут вещать люди которые такую же декомпозицию через большие сущности понимают но работают скажем с распределенными системами

Принцип локальности данных мол

Спойлер - ооп ему не противоречит. Просто надо перестать думать мячами и кирпичиками и воспринимать объекты как процессы

Да. Собственно моя начальная задача, в том, что я решил сделать игру на ООП, а не КОП ака ECS и понять, тае ли все плохо. Но чтобы это понять, мне важно правильно использовать ООП.

Вот я не понимаю в упор, почему цена кирпичика(за разрушение) должна храниться в кирпичике?

Я в целом думаю что ecs ближе к ооп)

У меня в голове, сидит иерархия, в которой есть cost_object, и кирпичик поле агрегируемое в нем.

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

Иерархии плохая идея

А есть хорошее чтиво которое делает акцент на объект=процесс?

Доки по симула и смолтоку)

Ну, я скорее, про то, что будет класс cost_object и два поля в нем - какой то объект, и его цена?

Хорошая это идея или нет зависит от того как данные юзать я будут.

Если серьезно можешь погуглить какие высказывания Алана Кея на эту тему, можешь погуглить и его интервью с создателем erlang - он там неплохую ретроспективу развитию ооп делал. Ну и публикации по actor model

Спасибо!

Ооп которое в плюсах ничем от структурного программирования не отличается, потому тут просто нет смысла искать интересные идеи

А "другое" ооп сегодня только в erlang или вот все эти попытки играть в микросервисы