В какой момент пора использовать ООП?
=======================================

**Добрый день.**  

Последние 5 лет разрабатываю веб-приложения (преимущественно для малого бизнеса). Работаю один и подрядчиков не привлекаю.  

Связка такая: PHP (иногда NodeJS) + MySQL (иногда Postgres и SQLite) + фронтэнд (подробно описывать не буду).  
  

Технология отлажена:  
* Клиент (браузер) обращается к нужной процедуре RPC API (посредством xmlHTTPRequest), при этом передает авторизационный токен
* Процедура обрабатывает входящие параметры, обращается, если нужно, к Базе данных (через класс PDO) и возвращает ответ в JSON клиенту.

  

От проекта к проекту могу копировать процедуры, чтобы не писать заново.  
  

Недавно прочел статью, суть которой была такой: **если вы не пишите в ООП стиле - вы лох.**  

Не то чтобы задело, но стало интересно, почему так?  
  

В таком случае мои API уже не должны сами обращаться к базе, а работать с экземлярами классов объектов.  

Кто может объяснить конкретные преимущества смены подхода?  

В какой момент (начиная с какого размера проекта) нужно переходить на ООП? 

 Не забивайте себе голову. Если всё работает и вас всё устраивает, то зачем что-то менять?  

Преимущества ООП проявляются при поддержке проекта.  

Вы поддерживаете свои проекты? Вы развиваете их? В какой момент вам стало сложно поддерживать проект?  

Много ли в проекте абстракций?  

Как вы решаете проблему добавления новых абстракций в проект?  
  

Если эти вопросы не про вас, то вам не нужно ООП. 

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

1) Инкапсуляция — мы прячем внутреннее состояние, давая его менять специальными выведенными наружу «рычажками».  

• Тесная работа с коммуникационными протоколами (например, почтой).  

• Поддержка какой-то вещи с меняющимся состоянием (в вебе этого мало — может, какая-нибудь автоматическая вёрстка?)  
  

2) Абстракция и полиморфизм — в общем, поддержка разных вещей под общим фасадом.  

• Неопределённость в технологиях — может, MySQL, а может, SqLite. Тогда создаём абстрактный класс «БД» и от него наследуем MySQL и SqLite.  

• Какие-нибудь штуки из предметной отрасли. Пишем игру — персонажей игры удобно так держать. Хотя можно ли написать многопользовательскую игру целиком на PHP — в этом я не уверен.  

• Ну, не знаю, где ещё. Настольная/мобильная версия, что ли? 

 Вот ему пора было использовать ООП:  

[www.gamedev.ru/projects/forum/?id=160897](http://www.gamedev.ru/projects/forum/?id=160897) (ссылки на скачивание исходников в первом посте, есть и фрагменты кода в других постах).  
  

У вас же не так все плохо? 

 Хотите понять зачем ООП? Поюзайте простенький фреймворк (к примеру Laravel 5). Изучите доки и т.д. сделайте простенький сайтик. И тогда я думаю вы поймёте как прелестна эта парадигма 

 Никто не привёл ни одного сколько-нибудь весомого аргумента в пользу ООП на PHP. Всё упирается «дружище, эх, попробуй и поймёшь, как это круто»  
  

Если мы создаём GUI-приложение, которое работает пока пользователь его не остановит, то там ООП действительно целесообразен, как минимум в процессе программирования интерфейса. Но в случае с PHP программа работает доли секунды (пока обрабатывает запрос) и тот же интерфейс программировать не нужно. Задачи программы на PHP: быть понятной, быть быстрой. И оба эти случая не об ООП.  
  

Чтобы быть понятной, программе нужна простая дружелюбная логика (это самый важный уровень абстракции, о котором забывают), код без дублей и документация. Чтобы быть быстрой ей как минимум не нужен лишний синтаксис.  
  

Анализируя тот же Laravel я вижу пару хороших вещей, которые логичнее реализовать в функциях и кучу кода ради кода.  
  

Вот пример <https://laravel.ru/docs/v3/database/fluent>  

$users = DB::table('users')->get();  
  

Но ничто нам не мешает написать полиморфную по логике функцию q():  
  

$users = q("users");  
  

Эта же функция может принимать SQL-запрос или более сложную над-SQL конструкцию, но при этом более понятную, чем цепь методов. Кто-то может возразить, что функция будет привязана к одному виду базы данных, но тем я напомню, что в зависимости от типа используемой базы ничто нам не мешает загружать нужный файл с соответствующей реализацией функции, к примеру, mysql.db.php postgresql.db.php  
  

Если логика процедурного кода сбалансирована, если нет дублей кода, если есть документация, то процедурный код будет лучше любого ООП кода по двум критериям: доступность для понимания, скорость работы. Учитывая, что ООП-код тоже требует балансировки и документации, преимущества процедурного становятся абсолютными. 

 в любой момент, ооп это удобно, позволяет использовать множество нужных! инструментов, позволяет писать меньше кода 

 >>В таком случае мои API уже не должны сами обращаться к базе, а работать с экземлярами классов объектов.  

Совсем не обязательно. То что вы описали:  

> Процедура обрабатывает входящие параметры, обращается, если нужно, к Базе данных (через класс PDO) и возвращает ответ в JSON клиенту.

  

можно назвать схемой model<->controller  

У вас в любом случае есть код, который отвечает за выборку данных, из какой таблицы брать, какую сортировку использовать и т.д. Кроме того есть какие-то общие вещи, которые используются везде. Все это дело можно вынести в один класс, скажем controllerClass.php и от него наследовать дочерние.  

На самом деле вполне можно обходиться и без ооп, но с ним код получается логичнее и понятнее + патерны. Вообщем лучше попробовать и сами все поймете. 

 ООП часто не нужно, особенно для простых проектов, сильно раздувает код. Притом часто под ООП некоторые понимают использование классов как пакетов для кода (что не есть ООП). Чтобы понять как использовать \_\_правильно\_\_ ООП прочитайте классику: Гради Буч: Объектно-ориентированное проектирование. 

 прочтите Зандстра 4-е изд. Где-то с Главы 6 Части 2. 

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

Во всяком случае, на текущих проектах ООП лучше не внедрять (огребете проблем). А вот что-то новое можно и начать. 

 Я работаю примерно также как вы - свой фреймворк, все отлажено и т.п. Несколько лет бьюсь в ООП, пытаюсь понять, где бы применить. Там, где применил, резко возрастала сложность.  
  

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

 Правильно научитесь ставить вопросы. Относительно вэб этот вопрос должен звучать так: В какой момент пора отказаться от использования ООП?  
  

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

 >если вы не пишите в ООП стиле - вы лох.  

Это уже устарело, сейчас в моде отказ от ООП! Посмотрите на go - процедурное программирование + интерфейсы.  

Посмотрите на Scala - функциональные подходы в Java экосистеме (сюда же Clojure и Kotlin).  

Во фронтенде сплошная функциональщина: ClojureScript, Elm, Purescript. Тот же модный нынче React+Redux.  
  

Так что смело забивайте на ООП и начните писать на Clojure + ClojureScript! 

 Лично у меня полное понимание зачем нужно ООП пришло лишь когда я прочитал книгу "Совершенный код".   

Прочитайте ее, это мастхев книга для любого программиста пишущего на ООП и (вдруг) без. Там даже есть такой раздел: "Разумные причина использования классов" где все детально разжевывается. С примерами.  
  

Если закрепите ее книгой Мэта Зандрста - то понимание будет еще глубже. 

[iantonov.me/page/pishem-sobstvennyj-mvc-frejmvork-...](http://iantonov.me/page/pishem-sobstvennyj-mvc-frejmvork-na-php)  
  

прочитай, изучи, сделай, в процессе поймешь. 

> Недавно прочел статью, суть которой была такой: если вы не пишите в ООП стиле - вы лох.  
> 
> Не то чтобы задело, но стало интересно, почему так?

 Если дело касается бизнес-логики (имхо это не менее 90% всего существующего в мире кода), то это так.  
  

В некоторых других областях он не всегда возможен или не нужен.