Стоит ли все function собирать в одном файле?

Question

[utyfua]

Добрый день
Стоит ли все function собирать в одном файле? даже если они использоваться не будут на определенной странице?
И стоит ли плодить около 5-10 функций для разборчивости кода?

Answer 1

[Сергей Протько]

Стоит ли все function собирать в одном файле?

Нет. Группируйте функции по их зоне ответственности. В целом вам просто должно быть удобно. Попробуйте через неделю найти какую-нибудь функцию и засеките сколько на это у вас ушло времени.

И стоит ли плодить около 5-10 функций для разборчивости кода?

Стоит. Это называется декомпозицией. Когда вы одну большую задачу (отобразить страницу) дробите на маленькие подзадачи. Велик шанс что на других страницах что-то из этого пригодится. Да и просто так удобнее. Маленькое проще править чем большое.

Comments

[utyfua]

а если функции могут быть на странице с 50% вероятности? Найти - да просто, сворачиваем блоки кода(использую notepad++) и вижу лишь списки функций.
А если функции по 5-15 строчек? Но эти строчки должны часто повторяться?

[Сергей Протько]

utyfua:

1) какая разница? Код кешируется в opcache, количество кода не влияет на производительность. Важно что бы код можно было ооочень легко найти.

2) найти - это древовидная структура. Когда все в одном файле - у вас все будет так или иначе со временем в перемешку.

3) все что повторяется (именно в плане логики работы а не кода) - в отдельные функции. Много много маленьких функций со временем приведут вас к древовидной структуре проекта.

[utyfua]

Сергей Протько: 1) код всегда смогу найти потому что пока только один проект и память есть
1) использую notepad++ и все это как на ладошке с простых функций.
3) вот тут возьму во внимание.

[Сергей Протько]

utyfua:

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

[utyfua]

Сергей Протько: 2) под сотню вряд ли будет и к тому же все функции сгруппированы по определенным их назначением.

Answer 2

[xmoonlight]

Функции делятся на 2 основных вида:
1. Вспомогательные - делятся по сферам применения и относительно форматов данных, с которыми они работают:
1.1 Языковые
1.2 Фильтрации данных
1.3 Работа со списками
1.4. Работа с очередями
и т.д.
2. Внутреклассовые - здесь и так понятно.

Каждый из этих пунктов должен быть включён через include_once() и ИСКЛЮЧИТЕЛЬНО! по мере необходимости для обеспечения функциональности, заданной БП.

Comments

[utyfua]

а множество инклудов не затормозит систему? а тем более include_once. я читал что его не желательно использовать вовсе..

[xmoonlight]

utyfua: 1. множество - это сколько?!
2. Есть кэш php-скриптов на сервере (у Вас - надеюсь, тоже). Я юзаю APC.
3. Про include_once - это интересно. Можно линк?

[utyfua]

xmoonlight: 1) еще пока не знаю но можно какие-то цифры?
2) я сам и не знаю есть ли подобное на хостинге. Спрошу..
3) https://www.yandex.ua/search/?text=php%20оптимизац...
на хабре: https://habrahabr.ru/post/22799/
7. require_once дорого обходится.

[Сергей Протько]

utyfua: делаем require всего в каком-нибудь autoload.php. Пусть opcache все тупо закэширует и пусть код все время лежит в памяти. Что бы интерпритатор не лазал на файловую систему на каждый запрос и все такое.

include_once очень медленная штука. Подход когда у вас все инклуды будут прописаны в одном месте спасает. Это не очень явно с точки зрения управления зависимостями но в целом норм, особенно если мы функции выносим в нэймспейсы и делаем их use. Повторюсь - если вы что-то с нуля пишите - используйте php7, там это удобнее.

xmoonlight: APC? opcache же, с версии 5.5 APC уже нет.

[utyfua]

Сергей Протько: а разница какая между require и include?

[Сергей Протько]

utyfua: с точки зрения opcache-а - ничем.

[xmoonlight]

Сергей Протько: да, все верно про opcache) у меня bufferoverflow)

[Dave]

utyfua: Если require() - не сможет загрузить файл, то скрипт прекратит выполнение и вылезит фатальная ошибка. Если include() - не сможет загрузить файл, то скрипт НЕ ПРЕКРАТИТ выполнение и вылезет предупреждение.

[utyfua]

Dave: спс

Answer 3

[Barmunk]

Посмотри в сторону публичных классов и их объектов, значительно упростишь себе жизнь

Comments

[utyfua]

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

[Barmunk]

utyfua: потребительности?

[utyfua]

Barmunk: да.. приложение не просто стоит а им пользуются. и сейчас вопрос ребром на его потребительность..

[Arris]

utyfua: может быть просто надо докинуть в сервер памяти?

[utyfua]

Arris: приложение хочу все переписать и вот вникаю в подобные вопросы.

[Сергей Протько]

Barmunk вот только не надо говорить что ООП это что бы "функции по классам раскидать". Да и зачем? подключили все файлики и opcache за нас все разрулил. Особенно если с composer-ом.

utyfua: Возможно вы не правильно их использовали? Накладные расходы на "классы" не такие уж и большие. Особенно в свете PHP7+. Зато ООП позволяет более грамотно построить систему, спрятать состояние и уменьшить сложность.

Просто никогда не говорите "никогда". Жизнь заставит. На процедурах с глобальным состоянием ничего сложного за адекватные сроки построить не выйдет.

[utyfua]

Сергей Протько: сейчас то я и использую php 7 но как-то в php 5.6 меня классы обидели..

[Сергей Протько]

utyfua: чем вас обидели классы?

[utyfua]

Сергей Протько: на тот момент потреблением памяти и скоростью работы..

[Сергей Протько]

utyfua: что ж вы такое делали что в классы уперлись.

[Сергей Протько]

utyfua: еще в php до 7.1 был такой нюанс - когда у вас более 10К объектов и есть циклические ссылки - то тогда ужасно педалил сборщик мусора. Но это не только классов касается - просто ссылки в массивах так же педалить будут, просто это надо явно написать так еще.

[utyfua]

Сергей Протько: был лишь один..

[Arris]

utyfua: плохому танцору яйца мешают.

[utyfua]

Arris: ну, вполне возможно что архитектурное решение было тогда печальное..

[xmoonlight]

utyfua: 3 варианта:
1. Вы же не сортировали в памяти данные, полученные из базы?
2. Парсинг файлов большого объёма?
3. Создание и уничтожение основного экземпляра класса в цикле, вместо наследования или клонирования?
Что-то из этого?)

[utyfua]

xmoonlight: 1) нет
2) нет
3) классов вообще нету кроме самого pdo

[xmoonlight]

utyfua: тогда в чём же была проблема, если не было классов?!

[utyfua]

xmoonlight: немного не в том контексте понял вопрос.
я однажды практически все впер в один класс и обращался к ней почти как к сторонней программе. Но это было не лучший вариант..

[xmoonlight]

utyfua: ну значит п.3 ) ясно.

[utyfua]

xmoonlight: нет - он в начале создавался и все на этом..

[utyfua]

xmoonlight: просто подход был скорее всего неверный.

[xmoonlight]

utyfua: ну да... иногда проще сделать один экземпляр объекта, а потом - прогнать через него массив данных, получив на выходе несколько объектов, вместо того, чтобы создавать копии экземпляров этого класса, что реально ресурсозатратно для CPU...

[utyfua]

xmoonlight: никаких дочерных классов не было тоже..

[xmoonlight]

utyfua: речь не про дочерние, а про КОПИИ: new XXX(); по циклу.

[utyfua]

xmoonlight: только 1 new во всем выполняемом коде был..

[xmoonlight]

utyfua: и не в рекурсии или в цикле он исполнялся, да?!))

[utyfua]

xmoonlight: было как-то так:
описание класса.
$c->set(чет) и таких строк 10
а потом echo $c->get
--
вродь так

[xmoonlight]

utyfua: смотря что там в $c->set().....

[utyfua]

xmoonlight: и там генерилось 10кб return...

[utyfua]

xmoonlight: и внутри еще инклуды были ну короч по ходу я мутил чет..

[utyfua]

xmoonlight: всеравно код мне поддерживать..

[xmoonlight]

utyfua: ОМГ! include внутри методов - вот и ответ!))))

[utyfua]

xmoonlight: а че не так если инклуды только в get и вложенные.

[xmoonlight]

utyfua: загрузка окружения для класса должна быть в конструкторе класса и больше нигде.

[utyfua]

xmoonlight: понятно.. ну это было почти год назад.. даже если так то не буду использовать, пока не понимаю истинную суть..

[xmoonlight]

utyfua: лучший вариант - это когда всё НЕОБХОДИМОЕ! (а не все подряд!) окружение грузится ранее инициализации всех классов в основном потоке. а уже после - используется ООП.

[utyfua]

xmoonlight: без него и так пока хорошо..

[Arris]

Слушайте, мы тут не занимаемся психологией. К чему эта дискуссия - убеждать человека, который НЕ ХОЧЕТ что-то, в том, что на самом деле... *безнадежно махнул рукой и отписался/*

[utyfua]

Arris: а разве вопрос в этом заключался?

[Антон Тихомиров]

И правда, как у вас вообще могли быть проблемы с классами, как? Во первых, первое замечание, нужно пользовать require, ибо в отличии от include он подключает файлы не останавливая работу скрипта, а параллельно. Потом это надо код Ваш смотреть, конечно, однако с большой долей вероятности Вы, небось, и запросы в БД в цикле выполняли... Так что действительно, не хочу Вас обидеть, но дело и правда в яйцах, не в классах :/

Answer 4

[Антон Тихомиров]

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