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

Question

[maks78945]

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

Я понимаю что это плохо и не правильно, но оно работает, хотел бы попросить у Вас совета, насколько это плохо, и можно ли использовать данный подход?

Comments

[Сергей c0re]

многие программы написаны на Си, а там именно процедурный стиль программирования, потому что там нет классов.

[ThunderCat]

Сергей, а многие программы не написаны на Си, и там есть классы... О чем это вообще?

[alex-1917]

ThunderCat, в любой непонятной ситуации я начинаю писать на дельфи

[Сергей c0re]

ThunderCat, Вам поговорить что ли охота? ))))
человек спросил плохо это или не плохо?
Смысл в том , что - Ни плохо, ни хорошо! и то и другое имеет место быть!

[ThunderCat]

Сергей,

Вам поговорить что ли охота? ))))

сказал человек написавший коммент в стиле "первыйя!".

человек спросил плохо это или не плохо?
Смысл в том , что - Ни плохо, ни хорошо! и то и другое имеет место быть!

Важно (и нужно) понимать разницу между языками в которых ооп вообще нет(в силу специфики, например низкоуровневости(внезапно)) и языками в которых он есть, и в которых принято на нем писать, ибо в этом есть потребность. В частности пых с 4.х ветки пошел в сторону ооп(что тоже не сразу), а начиная с 5.х код на ооп был уже практически стандартом, ибо большие проекты требуют совсем другой организации кода, чем просто лапша из функций вперемешку с хтмл. Так что совет "Ни плохо, ни хорошо!" == "деградируй дальше, все норм", из серии психологической помощи "примите себя какой вы есть, ну тупенький, не напрягайтесь...".

[Сергей c0re]

ThunderCat, из чего же вы такое умозаключение задвинули то? :)
спорить с вами нет желания....

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

Answer 1

[xmoonlight]

Проблема масштабируемости и расширяемости кода приложения.
Пока у Вас один тип объектов - можно всё писать и функциями (и хранить всё в массиве).
Но потом - придётся всё переписывать на классы и т.д.

Answer 2

[ThunderCat]

Зачем нужен ООП?
Кратко зачем ооп вместо функций:
1) Снижение сложности кода(да, звучит странно, но на самом деле именно так и есть - сложные вещи пишутся 1 раз, а далее вы пользуетесь практически предложениями естественного языка и описываем реально существующие манипуляции с реальными объектами, например $user->getName(), $image->rotateLeft()...)
2) Инкапсуляция - все что делает объект изолированно внутри одного инстанса, вы работаете по сути с отображением реальных объектов в цифровой мир(+ этот объект может быть сколь угодно сложным внутри, наружу он смотрит простыми методами для возможности операций над ним).
3) Снижение затрат памяти - классы подгружаются только в необходимом объеме и в нужно месте, в процедурном подходе все функции грузятся сразу.
4) Локализация кода - всегда логика одной сущности доступна в одном месте, не размазана по функциям и коду. Это такой нехилый бонус к инкапсуляции, и при рефакторинге вам не надо переписывать кучу кода, если объект был изначально правильно построен, максимум поменять немного логику внутренней обработки данных.

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

Я понимаю что это плохо и не правильно, но оно работает, хотел бы попросить у Вас совета, насколько это плохо, и можно ли использовать данный подход?

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

Answer 3

[Кирилл Несмеянов]

Если код пишется именно функциями, а не процедурами, то никаких проблем (в т.ч. с масштабируемостью) особо не будет. ООП в данном случае лишь поможет снизить сложность кода, т.к. композиция функций сложно читаема.

Answer 4

[Олег Фролов]

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

Answer 5

[Иван Шумов]

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

Comments

[xmoonlight]

Иван Шумов,

Плохо это то что судя по вашим же словам, вероятнее всего, у вас там дыры в безопасности размером со сверхновую

этот вывод из каких именно слов следует?

[Иван Шумов]

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

[xmoonlight]

Иван Шумов, 1. Про безопасность в тексте вопроса - ни слова.
2. Я могу писать и функциями с применением regex-фильтрации.
Это я к чему? Не нужно говорить то, чего нет. А ваши предположения и догадки относительно качества кода, который Вы даже не видели - оставьте при себе. (без обид...)