Минусующим: я в курсе что такое ООП и постоянно использую его в разработке. Или из-за чего вы там минусуете с пренебрежением к подобному подходу? Как это может быть ни удивительно для вас, но проекты можно писать в том числе и используя простые функции, вместо запихивания всего и вся в различные классы. Бывает множество ситуаций, когда функцию написать удобнее, чем городить целый класс для решения небольшой проблемы.
Есть один интересный подход при разработке проектов, который мне в последнее время стал нравиться. Суть простая: когда вы пишете функции — кладёте каждую из них в свой отдельный файл. Я сейчас имею ввиду те функции, которые используются во многих местах вашего проекта, формируя таким образом некоторую "библиотеку" методов.
Мало кто поступает таким образом в современном мире. Какие же профиты от такого подхода? А вот какие.
Красивые url'ы на любую функцию проекта
Многие из вас скорее всего неоднократно отправляли друг другу ссылки на различные отрезки кода на Github'е, вроде такого. Сегодня эта ссылка указывает точно на метод под названием booleanConditional. А вот на что эта ссылка будет указывать спустя пол года — на это мы посмотрим спустя пол года :) Ну, рискну предположить, что через пол года там будет мешанина какого-то совсем другого кода, никак не связанного с booleanConditional.
Если ваша функция будет лежать в своём собственном файле, то никаких смещений со временем не случится. Даже спустя долгое время после переработки проекта, ваша ссылка, скорее всего, не потеряет своей актуальности и будет указывать на всё ту же функцию, причём указывать она будет именно на её текущее актуальное содержимое.
Инкапсуляция кода и документации
Теперь у вас есть целый файл для вашей функции, в котором можно чего только про неё не понаписать! Всё, что будет написано в этом файле — относится только к этой функции. Описать конструкции импорта и использования нужных библиотек для её работы? Пожалуйста. Расписать большой комментарий, который детально расскажет, как должна вести себя ваша функция? Почему нет? Написать внизу примеры использования, завести обсуждение с коллегами о том, как можно её доработать? Оставить в комментариях прошлый вариант данной функции, чтобы, при необходимости, вернуться к нему обратно? Да пожалуйста, какие проблемы: берите и пишите сколько влезет.
Наличие отдельного файла для каждой функции сильно расширяет пространство для творчества. При этом, всё будет выглядеть очень удобно и логично. Когда мы описываем большое количество функций в одном большом жирном файле, мы не можем позволить себе подобные вольности.
Удобная "история жизни" каждой функции в VCS
Все мы знаем, что современные системы контроля версий позволяют смотреть историю изменения любого файла проекта. А теперь подумайте о том, как удобно может быть иметь историю жизни каждой его функции. Это также становится возможным просто благодаря тому, что мы выделили каждой своей функции по отдельному файлу.
Удобные поиск и навигация по функциям проекта
В нашем текущем проекте всё разбито следующим образом: есть ядро проекта и его модули. У ядра есть папка functions, в которой находятся ещё пять папок. Выглядит это следующим образом:
Каждый модуль проекта имеет свои собственные функции, разбитые примерно таким же образом.
Теперь найти нужную функцию проекта стало в несколько раз проще, при этом можно использовать почти любой редактор кода: главное чтобы он умел искать по названию файла в проекте. Разделение функций на группы по их областям назначения также помогает увеличить порядок проекта. Да и просто, когда всё разложено таким образом, анализировать существующие созданные методы проекта становится намного легче.
Недостатки
По идее, если мы ведём речь о PHP-проекте, то на продакшене, по хорошему, надо собирать все функции в один файл и загружать его одного вместо кучи файлов. Придётся написать немного кода для решения этой проблемы производительности (если это действительно вдруг станет проблемой), но это ведь не вопрос для вас, правда, мой друг-хабравчанин?
В мире JavaScript я никаких проблем не вижу. Там уже давно все адекватные люди компилируют исходники различными готовыми инструментами в один файл.
Насчёт остальных языков программирования я не знаю.
Вот такие пироги. На мой взгляд, так работать с проектом намного приятнее. А какое мнение по данной теме имеете вы?
Комментарии (54)
cry_san
05.10.2016 04:47+9Каждая идея имеет право на жизнь.
Иногда — не долгую…
saggid
05.10.2016 04:49+1Ну как сказать. Несколько месяцев уже прошло как мы стали пилить таким образом один большой проект. Пока что всё очень нравится, чем я и решил поделиться с сообществом. Возможно, мне укажут на проблемы, о которых я не подумал. А возможно — кому-то она даст пищу для размышления.
cry_san
05.10.2016 05:55Ну как минимум — куча открытых вкладок вместо одной в которой есть список по функциям.
Т.е. как минимум удобство редактирования.
Далее. Как передаете значения переменных? В классе есть, например, public переменная, которую могут использовать все функции класса. А в вашем случае общую переменную нужно тащить в параметры функции. А если их с десяток?saggid
05.10.2016 06:03+1Как я написал в самом начале статьи: я не отказывался ООП-подходов. Если функционал вырастает из размеров одной простой функции, просто берёшь и создаёшь новый класс в проекте и применяешь все фичи ООП, в которых возникает потребность.
Ну как минимум — куча открытых вкладок вместо одной в которой есть список по функциям.
Т.е. как минимум удобство редактирования.Если речь идёт о небольших функциях, то нет смысла открывать соседние. Каждая функция несёт в себе законченный независимый функционал, который решает определённую проблему. К примеру, вы можете создать функцию, которая находит координаты HTML-элемента на странице. Если у вас возникла проблема с этой функцией — вы работаете только с ней, с одной вкладкой.
Кстати, я сейчас ковырялся в исходных кодах jQuery. Там довольно часто используется подобный подход оказывается. Один файл — решение одной проблемы. Примеры: раз, два, три, и так далее.
Finesse
05.10.2016 08:03+1this — это, по-сути, аргумент, который передаётся в методы объекта неявно. В нём содержатся все параметры объекта, даже если их десятки. Таким образом, вместо класса можно использовать структуру и набор функций к ней.
P.S. Я не призываю пользоваться таким подходом.
seokirill
05.10.2016 07:57+1опять изобрели микросервисы?
saggid
05.10.2016 08:10-1Вы слышали такую фразу, как "всё гениальное — просто"? Современных программистов хлебом не корми, дай где-нибудь что-нибудь усложнить. Ведь когда сложно — это так ласкает наше ЧСВ, не правда ли? Сразу чувствуешь себя этаким Мозгом, решившим проблему таким Великим способом. Вы уже настолько больны этой заразой, что действительно простые методики разработки воспринимаете как нечто унизительное и недостойное внимания.
У меня другой подход в работе: я стараюсь максимально всё упрощать, насколько это вообще возможно. Чтобы больше времени уделять работе над задачами. Для меня код — это инструмент, а не религия и способ удовлетворения чувства собственной важности мозгодробительными конструкциями.
seokirill
05.10.2016 08:16оО
придерживаюсь того же подхода, но…
как это связано с моим комментарием оО?!saggid
05.10.2016 08:19Вы же вроде как намекаете, что я тут глупостями регулярно занимаюсь, как я понимаю. Хотя для меня это не глупости: скорее маленькие кусочки мудрости, к которым приходишь только спустя годы практики.
seokirill
05.10.2016 08:20+2гребете лопатой на себя.
я просто удивился, что вы заново открыли микросервисы
flancer
05.10.2016 11:50Если коротко, то архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Эти сервисы построены вокруг бизнес-потребностей и развертываются независимо с использованием полностью автоматизированной среды.
Микросервисы — современное представление сервис-ориентированной архитектуры (SOA), используемое для создания распределенных программных систем. Как и в SOA, модули в архитектуре микросервисов взаимодействуют по сети друг с другом для выполнения цели.Что-то я не заметил, чтобы коллега saggid предлагал использовать сетевые протоколы для вызова своих функций, так что сравнение с микросервисами удачно только в части "микро".
seokirill
05.10.2016 11:56Посыл абсолютно тот же, как их задействовать (по HTTP или просто вызывать соответствующие методы) — это уж детали.
Основная идея микросервисов в разделении логики на небольшие самодостаточные части.flancer
05.10.2016 12:06+2В таком случае — берите выше! Коллега saggid заново изобрел декомпозицию, которая является краеугольным камнем в разработке сложных систем. Посыл абсолютно тот же, а глобальность аналогии просто зашкаливающая. Круче может быть только изобрести заново двоичную систему.
Дъявол кроется в деталях, если что.
primepix
05.10.2016 09:11+6Хранение методов в файлах подходит только для методов-хелперов, которые обычно являются static методами в static классах (если ЯП поддерживает static для классов). Архитектурно разницы нет хранить ли такие методы в файле или в подобном классе.
Плюсы:
1. Некоторая наглядность
Минусы:
1. Сложности с PSR (если речь про пых)
2. Усложняется рефакторинг (недостаточно просто изменить имя метода, надо менять и имя файла)
3. Хранить в комментариях старую версию кода неправославно, для этого есть git и иже с ним
4. Появляется невольное желание создавать методы-гиганты
5. Если не используете namespace, то все методы будут глобальными, что совсем нехорошо.
6. Если используете namespace, то доп. сложности с рефакторингом.
7. Нестандартный подход > дополнительное обучение новых программистов
Если ваш проект небольшой, то вы вряд ли столкнетесь с большой болью от минусов.
Если вы храните в этих методах логику, т.е. это методы, которые должны быть в сервисе или модели, то дополнительно будут и архитектурные минусы (отсутствие состояния, невозможность наследования, невозможность DI, IoC и др.)saggid
05.10.2016 22:02-1Давайте рассмотрим внимательно каждый ваш пункт.
Сложности с PSR (если речь про пых)
Какие сложности? Одна простая функция загрузки функций решает все проблемы.
function include_dir($directory) { foreach (glob("{$directory}/*.php") as $filename) { require_once $filename; } } // Загрузим все функции нашего проекта include_dir(__DIR__ . '/functions')
Усложняется рефакторинг (недостаточно просто изменить имя метода, надо менять и имя файла)
А когда дело касается классов, то для вас проблемой не является, что их название тоже надо менять?)
Хранить в комментариях старую версию кода неправославно, для этого есть git и иже с ним
Я и не отрицал плюсы от VCS. Однако, почему бы и не написать в комментариях что-то насчёт вашей функции? Кто-то умрёт от этого? Зато лезть никуда не придётся, при необходимости.
Появляется невольное желание создавать методы-гиганты
Сдерживайте своё невольное желание, это не так уж и сложно, поверьте)
Если не используете namespace, то все методы будут глобальными, что совсем нехорошо.
Если ваш проект не является общедоступной библиотекой, ваша глобальная область видимости принадлежит только вам и позволяет делать вам с нею всё, что вашей душе угодно. Насчёт этого я уже написал внизу.
Если используете namespace, то доп. сложности с рефакторингом.
В данный момент я не вижу смысла для проекта, который не будет устанавливаться другим людям, использовать дополнительные namespace'ы.
Нестандартный подход > дополнительное обучение новых программистов
Подход нестандартный, но есть ли в нём что-то запредельно сложное для понимания?)
Если вы храните в этих методах логику, т.е. это методы, которые должны быть в сервисе или модели, то дополнительно будут и архитектурные минусы (отсутствие состояния, невозможность наследования, невозможность DI, IoC и др.)
Всегда ли так нужно это состояние? Так ли нужно наследование для метода, который явно делает какую-то одну конкретную и ясную вещь в проекте? Я в курсе насчёт всего этого и регулярно использую в работе. Но одно другому не мешает. И DI вполне возможен, да, не через конструктор класса, но у нас что, только такой метод получения зависимостей существует в мире?)
primepix
06.10.2016 14:33Ваши комментарии достаточно несостоятельны и эмоциональны, хотя это вы попросили привести недостатки вашего способа организации файлов. Складывается ощущение, что вы не желаете слушать аргументированные «за» и «против» и слепо верите в свой подход. Что ж, могу пожелать вам только удачи, надеюсь недостатки метода не коснутся вас, проекта, бизнеса. Иногда нужно пройтись и по граблям, чтобы накопить бесценный опыт.
saggid
06.10.2016 14:47-1Ну так я с вами не особо согласен по всем пунктам, простите уж меня за то, что у меня сформировалось ещё и своё мнение в противовес к вашему. С моей точки зрения, это ваши комментарии достаточно несостоятельны. Вы описали по большей части различные теоретические недостатки, в то время когда на практике я не нашёл проблем в описанных вами местах.
Мне были интересны действительно важные недостатки, из-за которых проект может работать как-то неправильно из-за подобного подхода. То, что описали вы — ну простите, что не угодил вам. Я их критичными проблемами не считаю.
flancer
07.10.2016 09:33+1Вам бы для начала, коллеги, договориться о единой шкале оценки предложенного подхода, а уже затем приводить аргументы в защиту своей точки зрения. Но я бы при таких вводных данных
… для проекта, который не будет устанавливаться другим людям
вообще не дискутировал на тему. В своем pet-проекте каждый волен писать код настолько феерично, насколько он чувствует потребность.
saggid
07.10.2016 21:58Этими словами я имел ввиду разницу между библиотекой, которая будет устанавливаться тысячам других людей и потенциально может сильно помешать им в их работе, и проектом, который является вашим сайтом на одном из фреймворков, к примеру. Большинство людей пишут всё-таки какие-то проекты, которые никогда не будут доступны общественности, только небольшим группам разработчиков, которые ведут разработку этого проекта и могу договориться друг с другом.
Я не имел ввиду здесь маленькие домашние проекты.
Повторю то, что я писал ранее: PHP весь работает на глобальных функциях. Живём ведь счастливо с этим делом. Всё потому, что эти глобальные функции всегда имеют один набор. Точно также можно сделать свой собственный набор дополнительных глобальных функций для своего собственного проекта, чтобы удобнее работать с ним. И я не вижу здесь проблем в разработке даже достаточно больших проектов. Тот проект, который мы делаем сейчас (образовательный портал с кучей модулей) — его маленьким не назовёшь.
И ещё раз повторю. Я не призываю писать вообще весь проект только на фукнциях. Упаси Господи от таких мыслей. ООП прекрасен, он позволяет делать массу крутых вещей. Но также бывают и множество ситуаций, когда создание класса является излишним, а иногда даже менее удобным, чем создание набора функций и расположение каждой из них в своём файле.
Onito
05.10.2016 09:24+1Вы это серьёзно? Для относительно простых и не имеющих конкретной области применения функций давно придумали такие саб-репозитории(или просто папки в проекте) с именем common, utils и тд. А вы предлагаете в крупном проекте где такие утилсы насчитывают тысячи функций городить под каждую файл? А потом удивляться что все компилируется намного дольше? Удобная история и дерево каталогов на каждую функцию? Ну удачи, с тысячей функций определённо удобно.
Ogra
05.10.2016 09:54А потом удивляться что все компилируется намного дольше?
Инкрементальная сборка значительно ускорится. Сборка с нуля либо ускорится за счет лучшей параллелизации, либо замедлится на время одной склейки всех исходников в один файл (читай — никак не увеличится).
AndreyDmitriev
05.10.2016 10:09+2Насчёт остальных языков программирования я не знаю.
Так сделано в LabVIEW — одна функция (точнее, один инструмент) — один файл, и по другому там нельзя (исключая, пожалуй, упакованные библиотеки и старые llb, но о них особый разговор).
Помимо раскладывания по папкам (это можно как по физическим на диске так и по виртуальным в проекте) файлы можно объединять в библиотеки (по сути их будет объединять XML файл со ссылками на индивидуальные файлы — функции).
С классами тоже самое — один метод — один физический файл на диске, объединённые в класс. Ну само собой, методам можно задавать Public/Protected/Private и всё такое.
Ну вот, к примеру, если взять первый попавшийся код примера из учебника:
using System; namespace BoxApplication { class Box { private double length; // Length of a box private double breadth; // Breadth of a box private double height; // Height of a box public void setLength( double len ) { length = len; } public void setBreadth( double bre ) { breadth = bre; } public void setHeight( double hei ) { height = hei; } public double getVolume() { return length * breadth * height; } } class Boxtester { static void Main(string[] args) { Box Box1 = new Box(); // Declare Box1 of type Box Box Box2 = new Box(); double volume; // Declare Box2 of type Box // box 1 specification Box1.setLength(6.0); Box1.setBreadth(7.0); Box1.setHeight(5.0); // box 2 specification Box2.setLength(12.0); Box2.setBreadth(13.0); Box2.setHeight(10.0); // volume of box 1 volume = Box1.getVolume(); Console.WriteLine("Volume of Box1 : {0}" ,volume); // volume of box 2 volume = Box2.getVolume(); Console.WriteLine("Volume of Box2 : {0}", volume); Console.ReadKey(); } } }
то эквивалентный код в LabVIEW и проект будет выглядеть как-то вот так:
на диске оно будет выглядеть вот так:
Собственно методы там вот какие:
Тут есть и плюсы и минусы — если делать классы или библиотеки-монстры и валить все методы и функции в одну папку, то потом разобраться будет непросто.
А изначально хорошее проектирование и грамотное разбиение на модули делает работу и последующую поддержку удобной. У меня довольно большой проект — дискомфорта нет, всё достаточно наглядно и прозрачно.
Ну и еще мы в команде накладываем строгое ограничение на размер кода — в смысле один инструмент-функция — один экран. Если код начинает разрастаться, то бьём это дело на более мелкие, либо организуем подприборы.telhin
06.10.2016 03:39Отладка в графическом режиме с большими уровнями вложенности не является затруднительной?
P.s. сам ваял программы размером с лист А1наверно это говорит о моей рукожопости. Сама идея графического программирования интересна, но требует специфических задач и оборудования для работы в окружении labview.AndreyDmitriev
06.10.2016 10:49Нет, там всё достаочно разумно сделано. Встроенные пробники и точки останова удобные, профилировщик приемлемый. Для тяжёлых случаев есть Desktop Execution Trace Toolkit, это для динамического анализа, а для статического мы используем VI Analyzer Toolkit.
Я достаточно быстро прошёл фазу «программ на А1», теперь я могу практически любую диаграмму быстро привести в компактный вид (впрочем я уже шестнадцать лет на LabVIEW программирую). В принципе ничто не мешает использовать эту среду как язык «общего назначения» — от специфического оборудования сама среда в общем-то не зависит, просто есть удобные библиотеки к железкам от того же производителя, что и LabVIEW. Задачи тоже не обязаны быть специфическими, но исторически так уж сложилось, что в основном LabVIEW используется либо в научной среде, (скажем в гамбургском синхротроне DESY много чего на LabVIEW сделано), либо в промышленности (я работаю в области промышленной автоматизации и машинного зрения в области неразрушающего рентгеновского контроля). Ну и ещё недетская стоимость продукта и библиотек останавливает широкое распространение — там ценник уже не на сотни, а на тысячи евро идёт.
michael_vostrikov
05.10.2016 10:32+3Сегодня эта ссылка указывает точно на метод под названием booleanConditional. А вот на что эта ссылка будет указывать спустя пол года — на это мы посмотрим спустя пол года
Поэтому надо указывать в URL не master, а хеш коммита. В результатах поиска github формирует ссылки с хешем.
https://github.com/systemjs/systemjs/blob/96fefe138ad4d60f46c3bdbb32a43490877209e7/lib/conditionals.js#L126-L147
Теперь найти нужную функцию проекта стало в несколько раз проще, при этом можно использовать почти любой редактор кода: главное чтобы он умел искать по названию файла в проекте
А в чем именно проще? Вместо одного поля надо написать название функции в другом поле.
У ядра есть папка functions, в которой находятся ещё пять папок
arrays
dates
strings
В языке есть средства группирования связанных функций, зачем переносить структуру кода на другой уровень в файловую систему?
Зачем вообще глобальные функции? С ними только лишние проблемы — с автозагрузкой, с засорением пространства имен. Все равно у связанных функций часто бывает одинаковое начало в названии — array_assoc_search, array_empty_keys.saggid
05.10.2016 21:42-1Поэтому надо указывать в URL не master, а хеш коммита
Ну окей, будет у вас ссылка на кусок кода, который был актуален когда-то давно, и сейчас он уже неактуален. О чём я и писал в статье, если вы не заметили.
А в чем именно проще? Вместо одного поля надо написать название функции в другом поле.
Читайте более внимательно. Банально не нужен редактор, поддерживающий анализ исходников проекта.
В языке есть средства группирования связанных функций, зачем переносить структуру кода на другой уровень в файловую систему?
Почему нет? Удобно же. Это позволяет сделать более приятной для изучения архитектуру проекта.
Зачем вообще глобальные функции? С ними только лишние проблемы — с автозагрузкой, с засорением пространства имен. Все равно у связанных функций часто бывает одинаковое начало в названии — array_assoc_search, array_empty_keys.
Весь PHP работает на основе глобальных функций. Как люди живут-то с ним? Вы в одну кашу смешали две разных вещи сейчас. Одно дело писать библиотеку, которую потом будет использовать большое количество людей в своих проектах. И там действительно глобальное пространство видимости засорять запрещено. И совсем другое дело — писать свой проект, глобальное пространство которого принадлежит вам и только вам, и вы вольны делать с ним всё, что пожелаете. У вас больше миллиарда допустимых вариантов для имён ваших функций. Вы никому не испортите жизнь таким подходом, ведь все эти функции будут работать только внутри вашего проекта.
andybelo
05.10.2016 11:18Проблема возникает, когда у вас много функций. Вот Возьмите механику. Что может быть сложней? Но там ограничились перемещением, вращением, шесть степеней свободы. И этого хватило для всей вселенной. Аналогично, для всех атомов хватило электрона, протона и нейтрона, ну ещё фотон. Для химии хватило 100 с лишним элементов. Для SQL хватило добавление, удаление, изменение, поиск, сортировка.
Ребята, Open GL ни кому не нужен. Любая библиотека с большим набором функций — сон разума.bromzh
05.10.2016 13:03+2Аналогично, для всех атомов хватило электрона, протона и нейтрона, ну ещё фотон.
Ну и ещё пи-мезоны, для "склейки" нуклонов. И кварки, из которых состоят протоны с нейтронами. И глюоны, для склейки кварков в эти протоны и нейтроны.
Аналогия с физикой не самая удачная, там всё не так просто
Idot
05.10.2016 13:29Такой подход при проектировании языков C и C++ породил проблемы. Там нет нормальной работы с UNICODE-строками, что привело к распуханию множества несовместимых библиотек.
Ребята, Open GL ни кому не нужен.
Думаешь в DirectX — лучше? Там каждая новая версия может оказаться нифига не совместимой с кодом написанной для старой версии DirectX. Что мягко сказать — очень неудобно для изучения в свободное от работы время.
PS в Геометрии 5 аксиом, однако, теоремы «зачем-то?» доказывают, а не считают лишними.andybelo
05.10.2016 14:28«Там нет нормальной работы с UNICODE-строками, что привело к распуханию»
То есть вы хотите сказать, каждый язык программирования должен иметь свою библиотеку для
работы с
1) PDF
2) jpeg
3) TCP/IP
4) распознавания образов
5) поиска максимума в 1 ТБ массиве
6)…
ну смешно же
KlimovDm
05.10.2016 13:01Роман, небольшое замечание. Такой метод организации файлов в принципе часто используется в других языках, в основном — в компилируемых (например, я так делаю на С). Но эти функции как правило собираются в библиотеку, поэтому по определению отсутствует описанный вами недостаток. Но и на production php, как мне кажется, не обязательно «склеивать» эту кучу маленьких файлов в одного монстра, достаточно правильно настроить opcache — так что описываемая вами проблема вроде и не проблема вовсе.
saggid
05.10.2016 21:50Дело в том, что просто на подключение всех файлов тоже тратится время. К примеру, Laravel позволяет компилировать все основные классы приложения в один файл на продакшене для ускорения работы проекта.
KlimovDm
05.10.2016 22:58Если вы о накладных расходах на обращение к файловой системе, то opcache.validate_timestamps=0 на продакшене по моему решает проблему.
saggid
06.10.2016 03:33Нет, это немного другое) Вы смешиваете разные вещи.
Представим, что в нашем проекте есть 1000 файлов, которые должны загрузиться при каждом запросе. Если вы установили
opcache.validate_timestampsв значение0, то PHP не будет проверять скрипты на изменения и будет просто загружать последний доступный скомпилированный код из своего кеша.
При этом, PHP всё также будет обращаться при каждом запросе 1000 раз к файловой системе для того чтобы получить каждый файл. А файловая система будет 1000 раз как минимум проверять наличие этого файла.
Вместо всего этого вы можете объединить вашу тысячу файлов в один большой жирный файл и таким образом сильно сократить количество работы для PHP и вашей файловой системы. Вместе с отключённым параметров
opcache.validate_timestamps, в итоге, вы можете добиться максимальной производительности. Что и можно сделать вместе с Laravel фреймворком прямо из коробки, к примеру.KlimovDm
06.10.2016 08:43>>>При этом, PHP всё также будет обращаться при каждом запросе 1000 раз к файловой системе для того чтобы получить каждый файл. А файловая система будет 1000 раз как минимум проверять наличие этого файла.
Вы удивитесь… но, это не так :) Логика кэширования в данном случае подразумевает и минимизацию обращения к файловой системе в том числе. Проверка наличия файла без валидации timestamp из этой логики выпадает (ну какой смысл?), поэтому наличие файла… не проверяется. Ну, если точнее, -то проверяется один раз — самый первый.
Ради интереса — проверьте сами.
К сожалению, я не могу красиво оформить сообщение, вставив готовый код, но уверен, что два php файла по одной строчке кода вы сами напишите. В основном include, в подключаемом — echo.
Настройки opcache сервера:
opcache.revalidate_freq=0
opcache.validate_timestamps=0
Выполнили запрос на веб-сервер (закэшировали)… Удалите подключаемый файл с echo. Еще запрос…saggid
06.10.2016 10:47Действительно, вы правы. Значит это дело реально отпадает, остаётся только то, что я написал ниже насчёт
spl_autoload_register.
К слову,
opcache.revalidate_freq=0делать не надо :)
; How often (in seconds) to check file timestamps for changes to the shared ; memory storage allocation. ("1" means validate once per second, but only ; once per request. "0" means always validate) ; opcache.revalidate_freq=2
saggid
06.10.2016 03:53Плюс, добавлю, что если вы склеили в один большой файл все свои основные классы, то это приведёт к тому, что ваш код автозагрузки, добавленный в систему с помощью
spl_autoload_register, не будет вызываться для данных основных классов: ведь они уже загрузились в систему, нет смысла вычислять возможные пути их местонахождения и потом пытаться загрузить.
RouR
05.10.2016 13:51Данный способ не означает отказа от ООП (зависит от языка программирования). Бывает partial class (.Net) который может быть написан в нескольких файлах.
http://stackoverflow.com/questions/21657684/partial-class-in-php-like-we-have-in-c-sharp
В целом это замедление компиляции (.Net), для PHP наверно тоже не очень хорошо с интерпретацией.
Не вижу плюсов на практике. Просматривать историю коммитов приходится редко (и слава богу)
chaetal
05.10.2016 15:23+1Ребята, вы так — глядишь — Smalltalk изобретете… лет так через 50 после оригинала ;)
gearbox
05.10.2016 16:42Похожая практика у меня с sql функциями (хранимки). При том что db клиент (http бэк) может обращаться только к хранимкам и никаких других запросов ( т.е. набор хранимок — это db api). ну в общем да, пока сухо и комфортно.
Shablonarium
06.10.2016 02:09-3А мне кажется, давно пора переходить от хранения кода в файлах к хранению в базе данных.
kentaskis
http://www.inpearls.ru/561894
saggid
Ок)
Am0ralist
мне больше нравится квн вариант:
— Зато теперь мы можем смело сказать, что все планы, которые мы перед собой ставили…
— клали…
— ложили…
— правильно «клали»
— не знаю, как правильно, а я положил.