jimon

ffinder
пример который привели на КРИ может говорить только о том что автор примера явно против ООП, потому что :
1) автор пытается совместить модель графической системы и модель игрового мира в одной архитектуре
2) автор пытается совместить пункт 1 с data driven engine
3) автор не учитывает существование такой професии как архитектор на котором висит создание всей ООП (и не ооп тоже) архитектуры проекта
4) дальше появляется какие-то статьи про обработчики ? callback'и ? так они еще большее зло чем любое ООП плюс сатана плюс обработчик ошибок, что обьясняется только догадками автора "ага етим заплатили 10 тыс $, а вторым только 5 тыс $, но вторые сделали калькулятор лутче, ага ага реализовывали на обработчиках в делфи"
5) все доверие подрывает постоянная путаница что такое игровое применение ООП, применение ООП в графическом движке и применение ООП при общем программировании
6) после всего этого автор обвиняет ООП в СВОИХ проблемах

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

процедурный подход нужен там где работают только с одной абстракцией (базы данных к примеру)
ООП подход нужен где нужна гибкость создания новых обьектов

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

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