Crash

ООП - это не только, когда вы берете какие-то сущности из предметной области и оборачиваете каждую в объект, который что-то умеет делать. Это больше подход к организации кода. Вы делите задачу на подзадачи, а данные на обособленные части, абстрагируете детали внутри объектов. Это позволяет снижать сложность архитектуры. Теоретически любую программу можно написать внутри одной огромной функции с кучей goto. Но так никто не делает, потому что это невозможно поддерживать и невероятно сложно написать. ООП - это логическое продолжение процедур. Теперь вы не только какие-то части программы абстрагируете в одном месте, но теперь еще и данные вмести с ними.

Мне нужен объект, который будет хранить состояние/данные, и есть общие операции над этим состоянием?

Вопрос: что значит нужен? Всегда можно взять глобальную переменную, написать функции, которые это состояние принимают и что-то с ним делают. Но довольно часто организация в виде объекта просто удобнее.

ФП – вообще про другое.
MVC – просто подход. спокойно реализуется и без ООП.

ООП – это управление сложностью/декомпозиция.
если вы делаете разовую маленькую задачу, заморачиваться им нет смысла.

Спасибо всем за развернутые ответы. Почитав все ответы и комментарии к ним, могу сделать следующий вывод. Может для кого это окажется слишком грубым, но большинства кто недовольны это просто жалующиеся лентяи .
Отвечу как автор вопрос на более популярные вопросы
1) Любой работник кроме ITшника после работы отдыхает а мы нет - Вы конечно простите но если вы не умеете правильно расставлять приоритеты , управлять своим временем, комбинировать работу и личную жизнь это полностью вашу вина, но никаким образом не вина самой работы.

2) Все учатся в процессе работы а ITшник в свободное от работы время - исходя из личного опыта, работая над задачей, поиск в гугле, решения в процессе работы и есть лучший метод учения. Т.е берешь задачу, даже сложную и вникаешь в нее по сути дела. Ошибаясь прокачиваешь свои навыки. И по моему скромному мнению в IT лучше всего это удается. Здесь вы не рискуйте практически ничем. В любой момент комбинации CTRL + Z вы можете вернутся и попробовать другой код, если текущий не работает. А может ли врач такое сделать? А может ли слесарь, инженер, электрик , спасатель, полицейский такое сделать?

3) Тут нету миллионов. Да я согласен, никто и не говорил что в IT , работая именно на компанию. Хотя не стоит исключать множество очень хорошо оплачиваемых программистов. Но всегда есть возможность открыть свое, так как весь бизнес сейчас в Digital. Многие тут приводили в пример юристов и бухгалтеров которые якобы хорошо открыли свой бизнес, якобы там больше возможностей но почему то никто не говорит о тех многочисленных юристов что без работы , либо вкалывают за гроши .

4) Все время лишь в мониторе . Опять же это только лично ваша проблема, есть такое что после работы за компьютером, устаешь морально, отпадает желания ходить куда то, и вместо прогулки многие смотрят ютуб под пивасик и играют в приставку. Если вы не можете правильно организовать свой отдых, после работы, найти увлечения, то это ваше дело

Резюмируя хочется сказать что тут многие приводят примеры которые не от IT иду, а от них самих. То что многие в данной сфере , заплывают , имеют проблемы со спиной , забивают на личную жизнь, на развития себя как личности. Это полностью их проблема. В жизни есть не только монитор и можно прокачивать себя в юморе, общения с людьми, быть интересным собеседником. Да может многое еще по молодости мне не понятно , ведь я имею мало опыта в данной сфере, но тут мне кажется люди спихнули все свои проблемы на профессию, не желая признаться что сами не развивают себя никаким образом, не развивают свой кругозор , и не умеют даже подержать шутку если она только не про PHP ( Ничего против php не имею )

чего?

1. Фрилансер - это черная дыра. Нет никаких гарантий, что вы с первого раза найдете хорошего специалиста. Вы потратите массу времени походив по рукам как портовая путана, потеряете массу времени и сил. В итоге скорее всего специалиста вы найдете, но какой ценой?

2. Нет слово бесплатно. Бесплатно будут работать только молодые специалисты, которых вы воспитаете. И то не долго, постепенно их интерес и отеческие симпатии пропадают, люди имеют свойство развиваться.

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

Вывод: Строить свою веб-студию можно только из своих коллег по цеху с которыми вы уже работали. Для этого желательно самому побыть фрилансером или же поработать в студии. Однако помимо кадровой работы у вас должна быть тонна знаний из разряда всего понемногу. Иначе вы останетесь без денег с лапшой на ушах

Мда, сколько же здесь страждующих. Аж грустно становится, какая по сути негативная среда. Я себе айти другим представлял. Мне кажется есть 2 варианта решения большинства проблем.

Если программированием заниматься не нравится

Менять деятельность срочно. Ждать 5-7 лет ошибка. Как и оправдывать все зависимостью от дохода. Я однажды занимался нелюбимым бизнесом и не знал как свалить. Зарабатывал неплохо (200-300), но была квартира-машина в кредит, другие кредиты и обязательства, постоянно вкладывал в автоматизацию, чтобы освободить время. Пока волей случая бизнес резко не навернулся, я продал ипотечную квартиру и мне ПРИШЛОСЬ от всего отказаться и заняться тем чем давно хотел попробовать. В итоге через 2 мес,как оказался без всего я купил первую квартиру уже без ипотеки. Потом много чего еще на что прошлым бизнесом не заработал бы за всю жизнь. Кредиты с тех пор ни разу не брал. Кайфовал от процесса, свободного времени стало в разы больше. Оказался в другом мире. И если бы бизнес не навернулся так и занимался бы фигней. А оказалось все бросить очень просто и быстро. И необходимо. Поэтому совет №1 - срочно менять деятельность. Нафиг любые прогнозы, ты даже не представляешь где можешь оказаться.

Если программированием заниматься нравится

Не работать сидя. Сидячая работа убивает и воздействует на продуктивность, настроение и т.д. Когда ты сидишь, организм готовится тупить и отдыхать. Кровь плохо функционирует. Гормональный фон плохой. Большинство, кто сидит часами каждый день имеют хронические проблемы со здоровьем физическим и психическим. Не замечают т.к. привыкли. И по статистике проживут меньше. Курить и бухать гораздо полезней чем сидеть. И веселей. Поэтому. Стол для работы стоя, веселая музыка, спорт-атрибуты и много движений. 8 часов такого программирования в день и через месяц будешь похож на спортсмена. При этом будешь выполнять задачи горадо быстрее, голова от притока крови работает лучше, настроение лучше и не будешь отвлекаться на Интернет. Правда, я никогда не писал код за деньги и не копался в чужом коде (если только на Тостере :)). Такой деятельностью тоже наврядли бы смог заниматься. Поэтому в твоем случае я бы смотрел в сторону первого варианта.

при 80% рано об этом думать.
ваш уровень - недостажер.

Java оборотов не сбавляла. платят за нее больше, спектр применения гораздо больше питона.

Не стоит поизучайте яву ещё года 3-4

Для начала почитайте что такое SAPI. Затем представьте что apache + mod_php разделили на web-сервер, который проксирует запросы на php-fpm и отдает статику, и собственно отдельный web-сервер который имплементит SAPI и выполняет запросы связанные только с php. То есть статику отдавать мы можем только через php. Суть примерно та же что и у apache2 + prefork + mod_php но оптимизированный только для работы с php. Так же можно поставить на фронт более быстрый и легковесный сервер который умеет проксировать запросы.

То есть php-fpm это эдакий fast-cgi сервер который постоянно держит готовые для работы пул-процессов (сколько в пуле процессов настраивается, так же как и от какого пользователя их запускать и все такое прочее). Каждый новый запрос уходит в какой-либо процесс из пула, запрос отрабатывает, возвращаем результат тому кто попросил (web-серверу обычно). Если процесс падает (fatal допустим) - поднимаем новый.

Принципиальной разницы между apache2+mod_php нету, просто упрощается инфраструктура. Наш web-сервер должен только уметь проксировать запросы и отдавать статику, а php-frpm вообще может быть на разных машинах (балансировщиком можно раскидывать запросы). Ну и сами понимаете, nginx + php-fpm будет быстрее обрабатывать запросы чем apache2+mod_php какой бы мы менеджер процессов не использовали в апаче. Минусов по сравнению с apache+mod_php я даже не могу предложить.

А php-runtime не зависит от этого. Он один на всех, CLI, FPM, mod_php...

Тут много нюансов и ответить однозначно сложно. Как уже написал Иван Шумов фреймворк - это инструмент. Каждый инструмент подбирается под конкретную задачу:

• СMS - система управления сайтом (Wordpress, Joomla и т.д.). Создан для простого и удобного управления сайтом (контентом). Как правило, доступен для работы простому пользователю, без знания языков программирования. Подойдёт для: простых сайтов, блогов, там где не требуется нагрузка и безопасность.
  
• RAD framework (Yii2) - фреймворк для быстрой разработки. RAD Фреймворк имеет, монолитную и связанную архитектуру. Он является антипаттенрном и позволяет вам делать всё что угодно, лишь бы вы быстро собрали свой проект. (Используется паттерн Table First - спроектировали базу и по схеме сгенерировали модели данных). При этом Вам никто не говорит, что он не может использоваться для серьёзных проектов. Например, DNS..
  
• Компонентные фреймворки (Symfony, Laravel). Это фреймворки, которые разделены на независимые компоненты, которые вы можете подключать к своему проекту при необходимости. В самом фреймворке заложен только необходимый минимум, а всё остальное вынесено в компоненты. Эти компоненты могут использоваться (или не использоваться). Могут использоваться для другого фреймворка (сам Yii2 использует компоненты симфони). Doctirine, которая позволяет вам забыть о базе данных и сосредоточиться на коде. Фреймворк задаёт вам некий стиль, некую структуру и типизацию и требует более хорошего и обдуманного кодинга. Например, при использовании twig вы не сможете сделать запрос в view. Чего нельзя сказать про Yii. Вы там можете построить хорошую бизнес логику, что и встречается...
  
• Микрофреймворки (Slim). В таких фреймворках заложен самый минимум, а всё остальное программист должен искать или писать самостоятельно, выстраивать свою архитектуру приложения. Он легкий и простой. Кто-то и Symfony относит к микрофреймворкам. Тут меня многие могут упрекнуть. Подойдет для очень простых, гибких, легких приложений, например, микросервисов. Фреймворк не задает вам никаких правил и архитектуры. Вы должны сами продумать все детали приложения. Где-то используете twig, где то Data Mapper, где-то ActiveRecord. Для работы с таким фреймворком требуется много знаний и опыта. Так как вам всё придется делать самому. Здесь за вас никто не подумал.
  

Что же для чего выбрать?
Решать вам исходя из конкретной задачи. Здесь нет понятия хуже/лучше. Чтобы что-то выбрать нужно на каждом попробовать собрать пару проектов. Тогда и будет понимание когда и что выбирать. Это как автомобиль. Какой лучше BMW или LADA? Оба автомобиля, но каждый для своей аудитории, по своим потребностям, для своих задач.

Почему другие говорят что Yii2 плохой?

• 2 версия морально устарела. Это не значит что ВЕСЬ фреймворк плохой, просто им давно никто не занимался. Сейчас идет разработка Yii3, которая многократно лучше 2 версии, но 3 версия доступна только в демо. Поэтому, если хочется писать НОВЫЙ проект на Yii, то я бы не стал выбирать 2 версию. Можете подождать Yii3, но никто не знает когда будет релиз. Можете начать писать используя Yii3-demo, но там может всё поменяться к моменту релиза.
  
• Он монолитный. Если вам требуется сделать проект используя много приложений с разными компонентами, то пойдёте по пути Advanced шаблона, где каждое приложение будет папкой: backend, forntend, console. Однако при большой нагрузке вам потребуется разносить приложения. Тогда ваш core будет дублироваться во всех приложениях. Там будет то, что вам даже не требуется. Потому что Yii2 монолит.
  
• В Yii2 используется Actvie Record. AR - это не плохо. Его многие любят, многие ценят и хвалят. Но для больших проектов он предоставляет неудобства. Например, при изменении поля в базе данных - приходится менять все свойства и надеяться что везде поменяли, так как в GrigView используется магия, при получение значений из модели 'value' => 'profile.last_name'. Так же нельзя сделать свойства модели (сущности), приватными. Из-за чего состояние модели можно изменить где угодно и вы никак не проконтролируете это.
  
• Много абстракции, которую не распознает редактор. Например, вы можете вызвать в контроллере Yii::$app->user->id. Вам приходится делать докблок, что User это common/auth/Identity, а не yii/web/User
  

Ну и так далее. С каждым из этих пунктов можно бороться, при правильном подходе. Как уже сказали в плохих руках любой код может пахнуть. Но это основное. Надеюсь, меня не раскритикуют другие за спорные моменты. В таких вопросах всегда есть разногласия) Думаю, что смог донести в сжатом виде отличия.

Могу ответить про postgresql.

без ее блокировки

Именно в такой постановке вопроса - никак.

С короткой блокировкой (доли секунд) - другое дело. Принципиально зависит от конкретного alter table и версии базы
Простой alter table foo add column col; - ставите statement_timeout to '100ms' и вносите как есть.
alter table foo add column col default const - после pg11 см. выше, до - интересное приключение
Если default не константа - сначала внесите как default null, затем обновляете частями. как в процессе до pg11.

Все эти страшные слова - они на самом деле всегда про одно и то же - про связность. Когда ты хардкодишь внутри класса вызов какого-то конкретного сервиса - ты намертво к нему привязываешься. И чтобы поменять сервис на другой, ты будешь вынужден поменять код класса. Окей, поменял. И тут же в другом месте, где этот же класс использовался, что-то сломалось! И что теперь? Делать два класса, которые различаются одной строчкой? Нет конечно. А как тогда использовать один и тот же класс для обработки разных входящих данных (или одних и тех же данных, но разными способами)? Сделать его поведение изменяемым. То есть сделать изменяемыми те инструменты, которыми он пользуется - т.е. его зависимости.

Поэтому все зависимости обычно передаются через конструктор (и поэтому и называются инъекция зависимостей.)

Таким образом мы можем менять поведение класса, не меняя его код

Но тут надо понимать, что всё это работает только при правильном применении ООП. А точнее просто при применении ООП. Потому что 98% "ООП" кода, который пишется на РНР - это голимая процедурщина, даже если она обёрнута в классы и методы. Если у тебя метод класса представляет из себя стену кода, которую ты тупо перенёс из файла, инклюдившегося в любимое похапешное спагетти - то это не ООП. Это та же процедурщина, вид сбоку. И смысл использования dependency injection ты с ним не почуствуешь. Будешь конечно применять, но в качестве карго культа - потому что тебе это на тостере написали.
А вот когда твой код начнет становиться действительно объектным - тогда стразу станет понятнее.

Похожим на сервис локатор является сервис- или DI-контейнер. Используемый вручную, он является тем же самым сервис локатором. Поэтому вручную его никогда не надо вызывать - что и запрещается в симфоневских конроллерах - а только для автоматического создания классов. В МВЦ у тебя ведь очень многие объекты создаются автоматом - сущности, контроллеры. И вот для того, чтобы при автоматическом создании экземпляра класса у тебя были на руках все требуемые сервисы - и нужен контейнер.

Соотвтственно, ответ на вопрос "что использовать?" очень простой:
- при ручном создании экземпляра объекта, все зависимости передавать в него через конструктор, а не получать "из воздуха" в коде.
- при автоматическом создании экземпляра объекта, использовать dependency injection container

В этим смысле очень полезно освоить Симфони - строгий фрейворк, в котором нет сервис локатора и в котором запрещено пользоваться контейнером напрямую.