anton_reut
@anton_reut
Начинающий веб-разработчик

Можно ли это переписать на ООП? И как примерно всё это можно распределить по классам?

У меня есть учебный проект (доска объявлений) и сейчас я переделываю структуру кода из процедурного в функциональный, в результате у меня образуются примерно такие группы функций:
function_items.php - всё что связано с записью в базу и выводом объявлений и операций с ними (например добавить в избранные)
function_users.php - всё что связано с пользователями, регистрация, вход, редактирования личной инфы и пр.
function_images.php - все операции с картинками, ресайз, обрезка, и пр.
И так далее разбиваю на группы функций.
Так вот, в плане обучения обязательно нужно освоить ООП (хотя бы основы но не на примерах машин и самолетов, а на живом коде) и я думаю как теперь это можно переделать в классы?
То есть, у меня, например, вместо файла function_items.php будет Class Items и всё что в этом файле будет в одном классе, так?
Но мне кажется, что мой код ещё не достаточно сложен чтобы его превращать в классы (классы это просто способ организации кода насколько я понимаю).
То есть, мне здесь пока ни к чему Инкапсуляция, Наследование и Полиморфизм, просто нет такой необходимости, или всё же есть? Прошу помочь в понимании нужно ли ООП в простых проектах или так и оставить в виде отдельных функций?
  • Вопрос задан
  • 668 просмотров
Пригласить эксперта
Ответы на вопрос 4
glaphire
@glaphire Куратор тега PHP
PHP developer
Попробуйте натянуть этот функционал на несложный фреймворк вроде laravel - да, он не идеальный, но как по мне лучше начать делать хоть как-то, а потом постепенно разбираться, как писать ООП красиво.
Items, users, images - могут стать классами моделей, где описаны их свойства и методы для их получения/записи.
Из function_images можно написать модуль (условно говоря папочку с набором классов-сервисов), где будет описана логика ресайза отдельно, логика обрезки отдельно и т.д.
Ответ написан
Комментировать
php666
@php666
PHP-макака
классы это просто способ организации кода насколько я понимаю
нет. вообще не правильно понимаешь.

Я тебе уже советовал читать Фаулера, ты это сделал? Ты задаешь одни и те же вопросы, на которые в принципе никто не сможет тебе ответить - это тема целой книги. Все советы тут будут лишь медвежьей услугой.

У тебя два пути:
1. Брать фреймворк и писать с нуля
2. Читать книгу и изобретать велосипед, переписывая свою лапшу на оо-стиль. Прокачаешься, но времени потратишь оооочень много, что будет крайне сомнительным действием в плане профита.
Ответ написан
gzhegow
@gzhegow
aka "ОбнимиБизнесмена"
Мне очень понравилось, как мне объяснил это Алексей Пастушенко

Так я понял что он сказал:
Смотри, компьютер все равно будет под капотом выполнять машинный код, процедурщину - функция в нее аргументы и поехали, а еще точнее - машинный код, логические И / ИЛИ, но думать так как машина здесь больше проблем чем преимуществ, хотя для общего развития можно просвятиться про диоды, транзисторы pn переходы и куда только не улетишь. Но если ты попробуешь на доске квадратами обрисовать что к чему цепляется, то у тебя миллион квадратов получится, ведь каждая функция это будет отдельный квадрат.

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

В действительности - косячит какая-то функция. Но когда есть некий обьект где она лежит, нам проще найти "виноватого" (модуль в коде) и пофиксить его.

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

Отдельная фишка это предсказуемость если в функцию приходят два обьекта которые должны как-то между собой взаимодействовать - то первое что придется делать это проверить - а то вообще пришло? В случае с ООП как минимум один из этих обьектов будет главным и его проверять не нужно (он будет $this). Либо это будет третий обьект, в который ты зашьешь проверку этих двух как будто это была простая функция. но код самой функции будет чище, т.к. проверки оказались в других местах, а здесь выполняется одно какое-то действие

В остальном ООП это усложнение кода, которое стоит того. Но если тебе нужно быренько связать два сайта через один скрипт, то попытка нарисовать карту этой связи выжрет у тебя неделю. А написать функцию, которая это делает - займет минут 10. Поэтому надо быренько сделать - забей. Надо предсказуемость, логируемость, понимание что где происходит, история изменений, или что самое ядерное - откат в обратном порядке от того, как это делалось - придется рисовать карту. Или сдохнуть на проекте
Ответ написан
@Vitsliputsli
например вместо файла function_items.php будет Class Items и всё что в этом файле будет в одном классе, так?

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

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

Войти через центр авторизации
Похожие вопросы