Мне очень понравилось, как мне объяснил это Алексей Пастушенко
Так я понял что он сказал:
Смотри, компьютер все равно будет под капотом выполнять машинный код, процедурщину - функция в нее аргументы и поехали, а еще точнее - машинный код, логические И / ИЛИ, но думать так как машина здесь больше проблем чем преимуществ, хотя для общего развития можно просвятиться про диоды, транзисторы pn переходы и куда только не улетишь. Но если ты попробуешь на доске квадратами обрисовать что к чему цепляется, то у тебя миллион квадратов получится, ведь каждая функция это будет отдельный квадрат.
ООП можно понимать как попытку нарисовать карту для какого-нибудь острова. Вот так будут изображаться порты, вот так - маяки. вот так будут леса. То есть в конечном счете прога будет работать на процедурщине. Но чтобы обьяснить её и найти в случае поломки код который косячит - мы рисуем карту и по ней пишем себе документацию, чтобы вспомнить что такой-то квадрат делает у нас тото и поэтому это он косячит. Важно понимать (у меня это отняло очень много времени, пока я воткнул) - что мы не "пишем на ООП", мы переписываем на ООП. Когда нужен функционал - мы пишем его на функциях, которые кладем в папку. А когда возникает необходимость следить за этим - кто где что в какой момент и пожалуйста с возможностью настраивать из админки - переписываем на ооп.
В действительности - косячит какая-то функция. Но когда есть некий обьект где она лежит, нам проще найти "виноватого" (модуль в коде) и пофиксить его.
Конечно от ООП и его использования есть и другие преимущества. Например - отойти от железно забитого в файл кода и возможность подменять целую логику подсунув новый класс с теми же функциями, но по другому. То есть ты не переписываешь все "если-то", ты на вход кидаешь целый кусок, который работает так же, но по своему.
Отдельная фишка это предсказуемость если в функцию приходят два обьекта которые должны как-то между собой взаимодействовать - то первое что придется делать это проверить - а то вообще пришло? В случае с ООП как минимум один из этих обьектов будет главным и его проверять не нужно (он будет $this). Либо это будет третий обьект, в который ты зашьешь проверку этих двух как будто это была простая функция. но код самой функции будет чище, т.к. проверки оказались в других местах, а здесь выполняется одно какое-то действие
В остальном ООП это усложнение кода, которое стоит того. Но если тебе нужно быренько связать два сайта через один скрипт, то попытка нарисовать карту этой связи выжрет у тебя неделю. А написать функцию, которая это делает - займет минут 10. Поэтому надо быренько сделать - забей. Надо предсказуемость, логируемость, понимание что где происходит, история изменений, или что самое ядерное - откат в обратном порядке от того, как это делалось - придется рисовать карту. Или сдохнуть на проекте
