@maks78945

Чем плохо написание кода функциями?

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

Я понимаю что это плохо и не правильно, но оно работает, хотел бы попросить у Вас совета, насколько это плохо, и можно ли использовать данный подход?
  • Вопрос задан
  • 201 просмотр
Пригласить эксперта
Ответы на вопрос 6
xmoonlight
@xmoonlight Куратор тега PHP
https://sitecoder.blogspot.com
Проблема масштабируемости и расширяемости кода приложения.
Пока у Вас один тип объектов - можно всё писать и функциями (и хранить всё в массиве).
Но потом - придётся всё переписывать на классы и т.д.
Ответ написан
ThunderCat
@ThunderCat Куратор тега PHP
{PHP, MySql, HTML, JS, CSS} developer
Зачем нужен ООП?
Кратко зачем ооп вместо функций:
1) Снижение сложности кода(да, звучит странно, но на самом деле именно так и есть - сложные вещи пишутся 1 раз, а далее вы пользуетесь практически предложениями естественного языка и описываем реально существующие манипуляции с реальными объектами, например $user->getName(), $image->rotateLeft()...)
2) Инкапсуляция - все что делает объект изолированно внутри одного инстанса, вы работаете по сути с отображением реальных объектов в цифровой мир(+ этот объект может быть сколь угодно сложным внутри, наружу он смотрит простыми методами для возможности операций над ним).
3) Снижение затрат памяти - классы подгружаются только в необходимом объеме и в нужно месте, в процедурном подходе все функции грузятся сразу.
4) Локализация кода - всегда логика одной сущности доступна в одном месте, не размазана по функциям и коду. Это такой нехилый бонус к инкапсуляции, и при рефакторинге вам не надо переписывать кучу кода, если объект был изначально правильно построен, максимум поменять немного логику внутренней обработки данных.

Про работу в команде я вообще молчу, модульность разработки позволяет много плюшек, от непересечения кода, до приоритетов конкретных задач под разработчика с большим опытом в каком-то конкретном направлении.

Я понимаю что это плохо и не правильно, но оно работает, хотел бы попросить у Вас совета, насколько это плохо, и можно ли использовать данный подход?
Почему нельзя?
Оно работает?
Оно решает проблему бизнеса на сейчас?
Бизнес устраивает решение которое "будет работать только здесь и сейчас, а стоимость погашения технического долга и расширения будет равна написанию приложения с нуля, но это будет потом"?
Если все ответы - "да" значит все не так уж плохо на сегодняшний день, и билет на само в порядке, по крайней мере пока вы работаете там.
Но я бы серьезно задумался о будущем в плане развития.
Ответ написан
SerafimArts
@SerafimArts
Laravel Framework Russian Community
Если код пишется именно функциями, а не процедурами, то никаких проблем (в т.ч. с масштабируемостью) особо не будет. ООП в данном случае лишь поможет снизить сложность кода, т.к. композиция функций сложно читаема.
Ответ написан
@Digiport
WebBasic CMS
Это ни хорошо, ни плохо. Просто существуют разные парадигмы - ООП и процедурная. Они могут использоваться как порознь, так и совместно Вопрос удобства и читаемости кода.
Ответ написан
@rustam_kuliev88
Судя по всему у Вас базовый паттерн MVC, это не плохо, у Вас отделены мухи от котлет, функции в Models а логика в controller, внешний вид в views все хорошо, это наоборот удобно на несложных проектах, да и при грамотном написании функций можно существенно экономить код, а поскольку напрямую вы не обращаетесь то и безопасность на уровне.
ООП это уже немного другой подход, но у Вас не процедурный стиль кода а MVC
если бы вы делали к примеру в index.php файл с вызовом функици из этого же файла это было бы не очень безопасно, практично, процедурный
Ответ написан
inoise
@inoise
Solutions Architect, AWS Certified, Hybrid Cloud
Писать так код не плохо. Плохо это то что судя по вашим же словам, вероятнее всего, у вас там дыры в безопасности размером со сверхновую, а также поддерживаемость этого на уровне плинтуса) а так, ничего - продолжайте)
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
от 55 000 до 80 000 руб.
WACDAQ Москва
от 120 000 руб.
Paxport Москва
от 140 000 до 190 000 руб.
21 авг. 2019, в 00:43
500 руб./за проект
21 авг. 2019, в 00:14
1000 руб./за проект