Когда нужно использовать ООП?

[Пепел Феникса]

вообще ООП не так тормозит как многие говорят.
это миф, поверьте.

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

Например, нужно написать многопоточный логгер событий, по сути метод с параметром строки. Как вы поступите? будете в приложение или юнит пихать переменную критической секции и инициализировать/финализировать ее в модуле? Еще несколько глобальных переменных имени файла, директории, чего-то еще... придумайте сами

в прооцедурном есть единица модуль это раз.
там будет обычная процедура Log(Logger:PLog;data:string) это при условии что логгер может быть не один.

[Utkin]

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

Да в лёт. Или по-Вашему до ООП жизни на планете Земля не было что-ли? Те же БД, ОСи и прочие сложные и замученные плюшки. Даже компиляторы были . На Коболе вон ООП не было, а Си++ по количеству написанного и что главное используемого кода не сильно уступает и ничего, живут люди.

[3D Hunter]

Последние два поста, как я понял, выступают в защиту процедурного типа тогда о чем вообще спор, господа? вопрос, который задал ТС, многогранный и неоднозначный. Бывает и правда процедуру легче написать чем класс ваять.

[Пепел Феникса]

ну как сказать, я более к тому что не нужно осуждать, клоню.
мне, лично, ООП приглянулось, стараюсь применять его.

[DiemonStar]

Да все им пользуются). Просто не люблю за излишний расход оперативки... при десятке-сотне объектов обычно это не столь заметно, но как только их количество разрастается, то нередко и всю память выедает этот бич компьютерный) и, что показательно, из всех возможностей объекта обычно используют лишь часть, а в память эта зараза лезет целиком) т.е., по-сути, часть оперативки занята ненужным мусором... Можно ссылаться на криворукость программеров, но таких программ море, где бездумно лепятся объекты, чтобы убрать десяток строк кода... ООП зачастую отучает людей думать...
Просто есть с чем сравнивать: видел программы обработки трёхмерных объектов летавшие на 386 процессорах, а счас подобное творение (ну может чуть более доработанное) требует не менее гигагерца в процессоре (а хватало-то всего 25Мгц и 1 Мб оперативки), видеокарты с поддержкой Директ Х... сколько это счастье (особенно с учётом библиотек директа) выедает из памяти вообще можно лучше промолчать)

[Utkin]

Это называется сговор между монополистами - производителями железа и софта . Не берите в голову.

[Пепел Феникса]

Просто есть с чем сравнивать: видел программы обработки трёхмерных объектов летавшие на 386 процессорах, а счас подобное творение (ну может чуть более доработанное) требует не менее гигагерца в процессоре (а хватало-то всего 25Мгц и 1 Мб оперативки), видеокарты с поддержкой Директ Х... сколько это счастье (особенно с учётом библиотек директа) выедает из памяти вообще можно лучше промолчать)

а качество/скорость не изменилось совсем?

Просто не люблю за излишний расход оперативки...

давайте не перекладывать кривые руки на само ООП.
да и не оно виновато. откажись от классов, будут структуры, расход памяти будет тот же.

[DiemonStar]

а качество/скорость не изменилось совсем?

скорость раза в три увеличилась... кадров с 40 до 130... и это при 40-кратном увеличении быстродействия (если мерять по мегагерцам, а если в общей производительности, то раз в 200)... не сильно впечатляет...

давайте не перекладывать кривые руки на само ООП.

оно сильно способствует их появлению: зачем писать лишний код, когда можно просто ткнуть объект)

откажись от классов, будут структуры, расход памяти будет тот же.

отнюдь не всегда... пару программ переделывал так, что уменьшались почти в 15 раз... а в оперативке выигрыш был порядка 40%

[Utkin]

отнюдь не всегда... пару программ переделывал так, что уменьшались почти в 15 раз... а в оперативке выигрыш был порядка 40%

Пока Вы сделаете свою маленькую и быструю программу, конкуренты давно уже продадут свои медленные и неэффективные. Зато написанные в десять раз быстрей . В этом и есть прикол - будете долго писать устареете раньше чем дойдете до логического завершения.

[GunSmoker]

Не стоит путать ООП как средство организации кода (если угодно - способ мышления) и ООП как поддержка со стороны языка.

"Код в ООП-стиле" можно писать на процедурах. Только будет это... тяжко.
Процедурный код можно писать на объектах. (Чем поголовно занимаются все студенты в Delphi.)