Програмёр "А для чего придумали ООП".
Мой ответ был "Для лучшего структурирования кода".


В общем, ты не был далёк от истины. Можно было бы конечно добавить ещё пару умных слов, но ...
Самое прикольное, что ООП, как и функциональное программирование, как и реляционные БД придумали не для чего-то конкретного, а просто, "чтобы було". Это -- подходы к разработке, методологии. Они -- ни для чего, они -- просто варианты реализации. Но многим понравилось так писать программы/базы данных -- и это получило распространение.
Другие люди, тоже "просто так" придумали, например, логическое программирование, аспектное программирование -- но оно "не покатило", и большой популярностью не пользуется.

ПрограмёрЯ предполагая, что речь идёт об производительности, сказал, что само по себе использование данного подхода приводит к небольшому снижению производительности (по отношению к функциональному программированию), однако этот недостаток можно перекрыть, так как код лучше структурирован, а потому может быть лучше оптимизирован.


Ну, этот тезис немного ни о чём. Производительность, ООП и функциональное программирование -- они никак друг с другом не связаны, это ортогональные категории. Каждая друг от друга совершенно не зависит.

ПрограмёрПоследующий разговор показал, что со мной не согласны, и ожидали ровно противоположного ответа (что производительность возростает при использовании объектов)


Ну, в принципе ты не так и неправ, поскольку инкапсуляция не даётся даром.

ПрограмёрИтак. Основной вопрос. Кто прав?


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

ПрограмёрКстати, по поводу MVC, то, что это сделано также для структурирования кода, он тоже не согласился..


Тут он прав, потому что MVC даёт возможность существования функциональности множества View и Controller к одному и тому же Model.
Типичный пример -- разные окна с Word-документов в разных режимах просмотра -- в одном пишешь, в другом -- смотришь, как это в итоге выглядит.
Кстати, MVC можно делать и без ООП.

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

Во всём остальном от тебя ожидают лояльности. Ты наверное прав в разрезе вопроса производительности
но окружающий тебя мир постепенно катиться к мульт-сериалу Футурама где гротеск и абсурд является трендом.
Сегодня все поклоняются золотому идолу под названием ООП. Просто так удобно. Прими это как факт.

Гы, много раз спорил, доказывал свою правоту, или доказывали мне, и я соглашался, и со вменяемыми представителями работодателя всегда "расставались друзьями".
А на невменяемых мне пофиг.

maytonПрограмёрЯростный Меч,

Да... я о процедурном )) как говорил, не любитель разной терминологии, потому иногда могу что-то подпутать ) Однако суть то не изменилась... программа написанная в стиле ООП не быстрее чем прога написанная процедурами (разумеется при одинаковой логике и функционале).
На одном веб семинаре звучало что у Java есть богатый функционал по
workaround виртуального каллбека. Но это от разработчика скрыто под капотом.
И наше понимание virtual callback если брать за основу С++-ное по отношению к Java
будет скорее всего ошибочным. Т.е. ООП в Java не равно ООП в С++. На этом
можно строить определённую риторику. И развивая мысль. ООП бывает разное.
И влияние его на скорость программы будет скорее всего более сложным
и многогранным. И ответить на этот вопрос в рамках собеседования скорее
всего невозможно. Надо рассматривать конкретные юзкейсы.

Ну кстати, да, вот характерный пример -- python, где, говорят, выражение

"2 + 3"
выполняется примерно след. образом:

создаётся объект '2' типа number

создаётся объект '3' типа number

создаётся (возможно, находится) объект '+' типа функция

функция '+' вызывается с двумя аргументами 'объект 2' и 'объект 3'

ПрограмёрЗначит ли это, что не используя данный паттерн, я не смогу написать тот же функционал, равный по производительности указанному (реализованному через (или как правильно говорится) MVC)?


Да, значит.
Не, ну, возможно, ты придумаешь какой-то другой аналогичный по назначению паттерн.

ПрограмёрТак всё же, может ли использование MVC шаблона в моих приложениях дать мне что-то, кроме понятной и удобной структуры проектов?


MVC вообще устроено по уму, только может быть пара VC (вместе или отдельно) вызывает небольшое недоумение.
Так что я не понимаю, как ещё можно было бы это сделать.

Основная идея (это кстати Subject-Observer называется) вполне интуитивно понятна -- есть кусок данных, который мы согласованно и централизованно меняем, и есть N наблюдателей, которые данные не меняют, но "слушают" события по изменению модели и перерисовывают их отображение.

Это можно сделать и без ООП и классов, на чистом С например, или на фортране. Ничего не изменится.

Ну это вообще бредовые показания...


Если бы это было так, то ядра операционных систем и баз данных писали бы на C++, а не на C. А то и вовсе на Java или C#.


Ядра ОС написаны на С а не на С++ по очень простому набору вполне понятных причин:
-- когда писались большинство ОС, С++ ещё не было
-- когда писались оставшаяся часть ОС, не существовало переносных компиляторов С++
-- Линус Торвальдс ненавидит С++. Это ничего не значит, это у него такое функциональное состояние (не болезнь, а именно функциональное состояние), навроде клаустрофобии или боязни высоты.



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


Как бы если тебе не хватает ума его не передавать, это твои личные проблемы. С++ не заставляет его передавать и использовать, да на самом деле С++ вообще никогда ничего не заставляет делать.



Конечно на C++ тоже можно массив структур, но это не приветствуется.

Почему же не приветствуется ? Кто мешает ?


Про Java и вовсе говорить не приходится - 101% примеров, где


А Ява тут вообще при чём ?