
Сделал бы вот так, это позволило бы выбирать, когда что удобнее обновлять. Или всё целиком.
<?php
declare(strict_types=1);
namespace App\Commands;
use Hleb\Base\Task;
use Modules\Admin\Controllers\ConsoleController;
/** php console refresh-data {arg} **/
class RefreshData extends Task
{
/**
* Resource regeneration and data update.
*/
protected function run(string $arg): int
{
match ($arg) {
'topics' => ConsoleController::topic(),
'posts' => ConsoleController::post(),
'up' => ConsoleController::up(),
'tl' => ConsoleController::tl(),
'all' => ConsoleController::all(),
default => throw new \InvalidArgumentException('Wrong argument: ' . $arg)
};
return self::SUCCESS_CODE;
}
}
Чтобы запускать задание на сервере вручную нужно определить где находится исполняемый файл php и указать путь до текущего проекта. Если PHP установлен в /usr/bin/php, то команда для запуска с обновлением всех данных:
/usr/bin/php /path/to/project/console refresh-data all
Если только темы нужно обновить:
/usr/bin/php /path/to/project/console refresh-data topics
Чтобы запускать через cron:
0 3 * * * /usr/bin/php /path/to/project/console refresh-data all
— запускать задачу ежедневно в 3:00 утра
PS Про запуск и крон я дописал для тех, кто этого не знает.
+
Ну то есть я бы сделал вот так, в методах ConsoleController есть уже такое разделение, а там кому как удобно. Более подробное описание как это работает …
+
PPS Вижу, что если нужно поправить ссылку, то редактирование недоступно сразу, так как сообщение добавилось к предыдущему… а оно вышло за срок редактирования. Можно было бы предыдущему изменить срок, но это весь принцип ограничений сбивает. Возможно, что можно придумать решение. Пока даю просто ссылку https://hleb2framework.ru/ru/2/0/console/command
Команду бы назвать более говорящим названием, по действию.
Тут много можно обсуждать на такие темы, но в начале сложилось впечатление, что вы сравниваете компетентное обращение с ФП против ООП которое пишут безалаберные программисты, а не сами принципы в чистом виде.
Ларавел просто здесь уже упоминался. В целом в интерпрайз много чего встретишь, но ООП там обязательно и это только небольшая часть. Всякие гексагональные архитектуры, диптреки, линтеры, анализаторы кода и прочее. Это все подразумевает наличие классов, как и сторонние библиотеки (с ними то что делать?). Сюда включены все крупные компании занимающиеся коммерческой деятельностью. Проекты там десятки тысяч строк (если монолит), не считая папки vendor и на php это хорошо ложится, так как он не компилируемый. То есть тут не вариант склонять их на смену парадигмы, так как иногда сложно такой проект просто на следующую версию php перевести…
Касаемо начать новый стартап в новом видении разработки, ну попробуйте, потом расскажете;)
Если брать микросервисы, то там та-же логика на десятки тысяч строк, только их уже больше и свои проблемы.
Если брать небольшие проекты, ну тут уже указал, что будут проблемы с подбором команды.
PS По части загрузки файлов тут не кажется более удобным, чем в PHP. Там автолоадинг прямо по неймспейсам. Все само работает.
По совместимости — как быть со сторонними библиотеками? Там все классы.
Решением тут может быть переписать такие либы через нейросеть, но такие объемы все равно не потянуть, а еще тесты и поддержка версий.
PPS Под «состоянием» имел ввиду текущие данные, которые обрабатывает код, в крупных проектах есть контракты, интерфейсы и прочее, чтобы не путать данные. Представляете, если ваш банк, который переводы делает онлайн будет хранить данные простыми массивами?
PPPS И вообще если принципиально не использовать ООП, как быть со стандартными классами PHP, например ошибками? Там есть определенная иерархия, начиная от общего интерфейса.
PPPS По поводу «класс одно действие» это неправильно трактуется. В оригинальной книге Р.Мартина «классом должен заведовать один актор», в этом плане класс вмещает больше, чем одна функция, которая в теории должна выполнять идемпотентные операции над чем-то одним.
что мешает набор функций распределять по разным файлам с четким названием?
Разве здесь не это подразумевалось? Просто если мы в один файл помещаем несколько функций, а нужна только одна, зачем грузить другие?
В целом ООП — это больше теория, на практике рекомендуется больше композиция, чем наследование.
Никто не мешает использовать комбинированный подход. Например, в Laravel куча функций из коробки идет, их можно использовать в проекте. Только вот этот фреймворк не подразумевает, что на нем будут писать только функциональный код.
Без фреймворка многие вещи нужно будет реализовывать самому. Для интерпрайз такой подход невыгоден (и еще по многим причинам), для собственного небольшого проекта наверное нормально, но опять же нужен фреймворк заранее подготовленный для такого. Может быть вы знаете такой?
И еще такой вопрос, насчет состояния. Вот есть данные запроса и данные пользователя. В каком виде это будет кочевать по функциям? В виде массивов? Но тогда как мы отличим массив с данными пользователя от какого-либо другого? Возрастает вероятность ошибки. В объектах это будет прямо в типах User и Request проверятся.
По автозагрузчику функций тоже нет ясности, где писать require, который загружает необходимую функцию для другой функции? В этом же файле? Тогда это будет require_once во избежание конфликтов, который не особо хорош для производительности. Да и вообще разделение на большее количество файлов проблемно для производительности в целом.
Теоретически проблем может и не быть, я даже написал, что можно процедурно написать проект на PHP и он будет работать. Можно даже без функций такое сделать. WordPress кажется, так и начинали:) Просто я не утверждаю, какой-то один подход корневым образом отличается от другого, там дело привычки. А насчет структуры… Методы в классах можно делать публичными и защищенными, как этого добиться с функциями?
Предлагается выше, что один файл — одна функция. В классе может быть несколько методов публичных, файл один, здесь же один метод видимо равен одной функции и несколько файлов в итоге загружать. Как вы представляете автозагрузчик таких функций в нужных местах?
Для классов есть автозагрузчик по требованию, с функциями вам нужно будет загружать файл с функцией, следить чтобы два раза не объявить и тд. Это не проблема, но потребует дополнительных ухищрений.
ООП — сейчас обязателен для командной разработки. Ео если вы в одиночку делаете проект и никому не показываете, то там может быть все процедурное, но со временем, когда он разрастется, трудно будет это все поддерживать, хотя таким образом можно огромный проект написать и он будет работать. А вот когда кто-то захочет присоединится или вы сами через пять лет решите восстановить в памяти, где там что, с этим будут проблемы. С классами хотя бы какая-то структура вырисовывается.
Как мне видится основная проблема современных нейросетей, что их создатели пытались их очеловечить. Если бы они выдавали сухую информацию примерно как в Википедии с ссылками откуда это взято, то претензий к ним было бы меньше. А пока они обманывают, юлят, кого-то могут даже вывести из себя этим, много негатива будет в их сторону. Из плюсов, умеет в анализ:
Проведи исследование на какой минуте хоккеист Овечкин забил больше всего шайб в своей карьере.
Ответ такой:
Больше всего голов Овечкин забил в промежутке минут 21−25
Но надо проверять) Поэтому для официальной статьи про спорт не годится.
Есть еще такая идея, чтобы не добавлять к предыдущему, если срок его редактирования вышел. Это будет и визуально разделение сообщений написанных сразу и с значительным интервалом.