Да как сказать Yii - это ящик с гаечными ключами. Можно ли по ящику понять - зачем ключи? Ну можно, если долго ключи использовать как пишут разработчики - то и поймешь со временем, но есть риск провалится в "делаю как сказали, почему - не знаю".
Коли про ООП вопрос: разработчикам нужно было писать меньше повторяющегося кода, чтобы не менять одно и то же по 10 раз. Давай по-порядку.
Представь ассоциативный массив (ключ-значение).
Теперь представь функцию, любую, пусть будет abs() - число по модулю.
А теперь забрось эту функцию в свой массив на место какого-нибудь ключа, то есть у тебя как будто получится $array["abs"], где лежит сама функция.
В чем отличие функции от других данных? Данные ты можешь записать, а можешь считать. А функцию ты еще и выполнить можешь. Таким образом когда ты ее вкинул в массив, у тебя лежит не функция там, а ее заготовка, под выполнение. И ты можешь ее вызвать но уже не как abs(), а как $arr['abs']() - что будет выглядеть одинаково (под капотом все сложнее, но пока забей, оно тебе не надо)
А теперь представь что у тебя есть десять таких массивов $arr. И что, в каждый теперь совать функцию, которую ты только что запихнул в первый? Нет, зачем. Для этого существуют "классы" - которые описывают внешний вид будущего "массива".
Таким образом ООП это когда ты сначала описываешь внешний вид массива, а потом создаешь вот эти "улучшенные массивы" по описанному виду. Но это только малая часть всего движа.
Тут есть тема - взять тип массива (класс), и на его основе сделать другой класс, чтобы не переписывать сначала.
Тут есть тема - создать свой собственный тип данных и проверять его при передаче из функции в функцию.
Есть тема - что ты можешь помимо типа массива задать еще более высокую степень организации "требования к типу массивов" - то есть интефейс - "все описанные типы массива должны иметь такой-то метод и такие то свойства, если нет - пнуть разраба, что он дурак"...
По большей части многие из этих фишек и движняков являются плодом больной фантазии ума разработчиков, требующих самореализации. Ну то есть скачать прайс-лист экселя и разобрать можно и на массивах, слить два прайс-листа в один по нескольким полям - тоже можно на массивах.
Вся эта канитель с ООП - это когда тебе действительно нужна реактивная артиллерия - ты хочешь написать код в который - кого не посади - дибила или умника или еще кого - он не сможет ничего сломать. Но он все равно сможет, поэтому часто работа над ООП вываливается в цикл в стиле "правлю то что никому не пригодится, но я знаю что однажды это упадет и потому правлю".
Об ООП стоит думать как средство уменьшения числа кода. Если у тебя к примеру два поставщика и два разных файла выгрузки, а действия в них одни и те же - можно прибегнуть к ООП, сделав тип "Поставщик" и описав в нем - что он умеет делать над своими "экземплярами-объектами-улучшенными_массивами" и тд.
Прежде чем считать, что ты не сможешь без ООП тебе нужно понять, что любая вещь МОЖЕТ быть сделана без ООП. Просто количество путаницы если ты бросишь этот код и вернешься к нему через месяц и уже не помнишь что где и когда - будет больше. Классы создают некую описательную структуру того, что происходит и оттого часто в крупных проектах писать на ООП длиннее дольше и тяжелее, чем без ООП.
То есть штуку разрабатывали чтобы писать меньше, а на деле для понимания все переменные в верблюде пишут, и в итоге кода еще больше становится, но он типа "понятный". А потом они будут перебирать дорогих сотрудников, потому что дешевые этот понятный код не могут писать, тобто ребята копошаться в своих головах, а деньги приносят продажи потом. Не попадись в такую ловушку.
ООП тебе понадобится, когда у тебя возникнет очень отчетливое чувство что "блин, вот язык этот какое дерьмо, мне так задрало вот эту штуку каждый раз заново писать, почему они сразу этого не сделали?" - вот тогда тебе надо заняться ООП, и тогда его будет легко понять.
Я не про то, что типа "еще рано" и тд. Я про то, что есть куча вещей в которое можно отдать время, более интересных и полезных, чем погружаться с башкой в эту муть, которая на деле кроме чувства мнимого превосходства тебе ничего не даст. Просто делай как удобно, и только когда решишь своим массивам задавать поведение - типа "при присвоении ключа в поле `name` автоматически создать поле `code` с таким-то содержимым" - вот тогда реально можешь повкуривать что тут еще можно мутить.
