Задать вопрос
Surzhikov
@Surzhikov
Разработчик

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

Добрый день.
Последние 5 лет разрабатываю веб-приложения (преимущественно для малого бизнеса). Работаю один и подрядчиков не привлекаю.
Связка такая: PHP (иногда NodeJS) + MySQL (иногда Postgres и SQLite) + фронтэнд (подробно описывать не буду).

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

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

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

В таком случае мои API уже не должны сами обращаться к базе, а работать с экземлярами классов объектов.
Кто может объяснить конкретные преимущества смены подхода?
В какой момент (начиная с какого размера проекта) нужно переходить на ООП?
  • Вопрос задан
  • 3169 просмотров
Подписаться 23 Оценить 1 комментарий
Пригласить эксперта
Ответы на вопрос 13
Denormalization
@Denormalization
Не забивайте себе голову. Если всё работает и вас всё устраивает, то зачем что-то менять?
Преимущества ООП проявляются при поддержке проекта.
Вы поддерживаете свои проекты? Вы развиваете их? В какой момент вам стало сложно поддерживать проект?
Много ли в проекте абстракций?
Как вы решаете проблему добавления новых абстракций в проект?

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

1) Инкапсуляция — мы прячем внутреннее состояние, давая его менять специальными выведенными наружу «рычажками».
• Тесная работа с коммуникационными протоколами (например, почтой).
• Поддержка какой-то вещи с меняющимся состоянием (в вебе этого мало — может, какая-нибудь автоматическая вёрстка?)

2) Абстракция и полиморфизм — в общем, поддержка разных вещей под общим фасадом.
• Неопределённость в технологиях — может, MySQL, а может, SqLite. Тогда создаём абстрактный класс «БД» и от него наследуем MySQL и SqLite.
• Какие-нибудь штуки из предметной отрасли. Пишем игру — персонажей игры удобно так держать. Хотя можно ли написать многопользовательскую игру целиком на PHP — в этом я не уверен.
• Ну, не знаю, где ещё. Настольная/мобильная версия, что ли?
Ответ написан
Комментировать
Вот ему пора было использовать ООП:
www.gamedev.ru/projects/forum/?id=160897 (ссылки на скачивание исходников в первом посте, есть и фрагменты кода в других постах).

У вас же не так все плохо?
Ответ написан
Комментировать
@vGrabko99
html, css, js, php, golang, mysql
Хотите понять зачем ООП? Поюзайте простенький фреймворк (к примеру Laravel 5). Изучите доки и т.д. сделайте простенький сайтик. И тогда я думаю вы поймёте как прелестна эта парадигма
Ответ написан
@roskoshinsky
Никто не привёл ни одного сколько-нибудь весомого аргумента в пользу ООП на 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

Если логика процедурного кода сбалансирована, если нет дублей кода, если есть документация, то процедурный код будет лучше любого ООП кода по двум критериям: доступность для понимания, скорость работы. Учитывая, что ООП-код тоже требует балансировки и документации, преимущества процедурного становятся абсолютными.
Ответ написан
@sl1m_dogg
в любой момент, ооп это удобно, позволяет использовать множество нужных! инструментов, позволяет писать меньше кода
Ответ написан
Комментировать
@kstyle
прочтите Зандстра 4-е изд. Где-то с Главы 6 Части 2.
Ответ написан
Комментировать
@thyratr0n
Что-то даже хз, что и ответить... ООП - это принципиально иная парадигма разработки, нежели процедурный стиль. Вообще, ваш случай довольно интересный, когда аж 5 лет устраивает процедурный стиль.
Во всяком случае, на текущих проектах ООП лучше не внедрять (огребете проблем). А вот что-то новое можно и начать.
Ответ написан
Комментировать
Stac
@Stac
Я работаю примерно также как вы - свой фреймворк, все отлажено и т.п. Несколько лет бьюсь в ООП, пытаюсь понять, где бы применить. Там, где применил, резко возрастала сложность.

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

Для понимания этого сложного момента попробуйте запилить несколько сайтов на ООП фреймворках. Можно на нескольких, а можно на одном хорошем. Не суть важно. В какой-то момент вы поймаете эту тонкую грань.
Ответ написан
Комментировать
PQR
@PQR
>если вы не пишите в ООП стиле - вы лох.
Это уже устарело, сейчас в моде отказ от ООП! Посмотрите на go - процедурное программирование + интерфейсы.
Посмотрите на Scala - функциональные подходы в Java экосистеме (сюда же Clojure и Kotlin).
Во фронтенде сплошная функциональщина: ClojureScript, Elm, Purescript. Тот же модный нынче React+Redux.

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

Если закрепите ее книгой Мэта Зандрста - то понимание будет еще глубже.
Ответ написан
Комментировать
rsivakov
@rsivakov
Digital Cowboy
iantonov.me/page/pishem-sobstvennyj-mvc-frejmvork-...

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

Войдите, чтобы написать ответ

Похожие вопросы