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

[3D Hunter]

По поводу 40-130 fps - откуда взялись эти цифры? Давайте уже тесты, доказательства, обзоры в студию! Голословничать не нужно. Что касается громадного ужрания оперативки современными программами, это факт, поддерживаю. Веяния моды кросплатформенности - почти каждая новая программа тащит с собой смесь библиотек сишных и си-шарповских, кои использовать конечно удобно и быстро, ведь многое уже реализовано. Стандарты делают свое дело. В принципе оно и верно - зачем писать каждый раз то, что по логике и смыслу должно быть априори? Посмотрите на тот же VCL и далеко ходить не надо. Удобство и гибкость, но памяти больше ест. В скорости уступает WinApi? Я бы призадумался, прежде чем говорить "да" или "нет". Вот и принцип библиотек тот же. Зачем реализовывать часто используемые вещи? На, пользуйся, вот готовый, качественный, проверенный и оттестированный код в виде классов, модулей, com-объектов, dll-ок и т.п.
Другой вопрос в том, как именно писать свой код. Наверно все-таки смотря какой код и откуда руки растут и извилины у пишущего все индивидуально. Хотя я лично сложные проекты всегда пишу классами, выделяю отдельные механизмы, абстрагирую логику, пишу механизмы взаимодействия между классами. ИМХО, это сразу верный и дальновидный подход. Пусть главный поток занимается отрисовкой интерфейса и обработкой сообщений, а всю работу делают потоки. Ну как-то так наверное...
И еще по поводу директов Иксовых и и им подобным. Неверно сравнивать в линейной зависимости соотношение мегагерцев процессоров и качество графики по своей субъективной шкале. Вам кажется, что эффекты не очень улучшились, а чтобы его создать, может потребовалось написать огромный шейдер, коих, кстати, тоже библиотек готовых немало. И не надо тут говорить про говно-код и криворуки. Люди отлаживали их годами, основы движков одинаковы.
Итог всего выше сказанного - люди облегчают процесс работы тем, что нарабатывают готовые механизмы, которые помогают им быстрее и эффективнее создавать более сложные продукты. А кривые руки - это другая история и путать не надо с нормальным пониманием полезных вещей.
К слову, в моем ПО есть самое главное приложение, в котором работает до 1000 потоков одновременно и в каждом из них постоянно что-то делается при поступлении информации. Пиковая загрузка ЦП составляла 5-6%, проц 4х-ядерный. Памяти жрется максимум 50 мб. Много для серверной части? И даже для клиентской машины? Да ну

P.S. Как же я задрался писать это

[s-andriano]

Сообщение от Пепел Феникса

а что матрица не имеет доступа к своим же данным?
и данным такого же класса как она?
инкапсулировать нужно грамотно.

Вот это "грамотно инкапсулировать" и интересует.

[s-andriano]

Сообщение от Utkin

Конкретно в Дельфи через юнит можно попробовать. Не выносите объявления в interface. Вообще люди сильно накручены ООП, реально даже если будут видны массивы структур это не обязательно приведет к ошибкам.

Можно.
Но ровно до тех пор, пока нам не понадобится второй/третий/четвертый экземпляр набора данных, описанных в этом модуле.

[s-andriano]

Сообщение от DiemonStar

Да все им пользуются). Просто не люблю за излишний расход оперативки...

Нету такого. Несколько десятков-сотен байт на объект погоды не сделают.

при десятке-сотне объектов обычно это не столь заметно, но как только их количество разрастается, то нередко и всю память выедает этот бич компьютерный)

А тут уже банальная ошибка проектирования.
Если некоторую сущность планируется плодить в тысячах или более экземпляров, то объектом должна быть не единица а массив.
Живой пример (меня он, помнится, в свое время поразил):
Написал я объект для работы с XML. На его основе сделал программку для проекта, отослал ее координатору проекта. Программа должна была экспортировать БД нестандартного формата в XML. Время работы программы составило около 2.5 секунд.
Получаю письмо, что программа, которая должна была "засосать" сформированный XML, зависает на том, что сформировала моя программа.
В дальнейшем выяснилось, что дело не в зависании, а в том, что программист, писавший программу, которая читала мои данные, воспользовался майкрософтовским парсером. А ему на чтение фала понадобилось более 10 минут.
А разница - как раз на этапе проектирования: у Майкрософт объект - каждый элемент XML, а у меня объект - весь XML-файл. Соответственно, майкрософтовский парсер дергает диспетчер памяти миллионы раз, а мой - единицы.

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

В этом отношении оно ничем не хуже процедурного.
Разве что тем, что требует более тщательного проектирования.

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

Это все верно, только ООП то здесь при чем?

[Человек_Борща]

Предлогаю перенести обсуждение в "Свободное общение".

[s-andriano]

А зачем профильную тему переносить в непрофильный раздел.

[3D Hunter]

Давайте закроем тему и всех делофф чую, до добра не доведет

[Utkin]

Но ровно до тех пор, пока нам не понадобится второй/третий/четвертый экземпляр набора данных, описанных в этом модуле.

Загнал в динамический массив . Разные точки зрения на задачу - один результат.

Давайте закроем тему и всех делофф чую, до добра не доведет

Не, давайте посмотрим на мнения остальных...

[Человек_Борща]

А зачем профильную тему переносить в непрофильный раздел.

Там больше людей крутиться. А тут, только делфисты, или те, кто знает delphi и ещё что-то.

Тема актуальна для всех языков программирования.

перенесите тему.

[3D Hunter]

Ладно, давайте поститься переносите, поддерживаю!