Comments 44
Если речь идет о PHP, то какой смысл использовать классы в качестве неймспейсов, если можно просто положить обычную функцию в неймспейс? Что за мода всюду пихать классы? Объекты нужны для связи данных и методов, которые их обрабатывают. Если метод чистый, то это обычная фукция и классы тут не нужны. Каждой задаче — свой инструмент!
-1
Потому-то для функций не сделали автолоадера.
+5
UFO just landed and posted this here
UFO just landed and posted this here
Видимо, использование классов вместо неймспейсов считается меньшим злом, чем приведённый вами извращения )
0
Да нет, просто большинство просто не знают что так можно делать :)
0
слава бгу и так говнокода полно
-1
Использовать функции — говнокод? Странное заявление как минимум, от человека, который ежедневно использует функции.
-1
В каком месте я утверждал, что использование фукнции — говнокод?
0
Ветка про использование функций в неймспейсах, и код про использование функции вы назвали извращением и на фразу «так не делают потому что не знают» вы ответили «слава богу, говнокода итак хватает». Вывод сам собой пришел.
0
для любителей автолоада тоже есть выход
`
final class my_function1 {
static function run($a) {
return "а я люблю собирать функции в классы ";
}
}
final class my_function2 {
static function run($a) {
return " и обмазыватся автолоадом";
}
}
echo my_function1::run(). my_function2::run()
`
да еще для любителе попрятать "всякие приватные механики" будет радость
`
final class my_function1 {
static function run($a) {
return "а я люблю собирать функции в классы ";
}
}
final class my_function2 {
static function run($a) {
return " и обмазыватся автолоадом";
}
}
echo my_function1::run(). my_function2::run()
`
да еще для любителе попрятать "всякие приватные механики" будет радость
0
В этом случае лучше использовать __invoke(), тогда получится просто echo my_function1(). Хотя тоже очень на любителя…
0
всегда думал что это работает только для объектов а не для классов
и вправда не работает — так бы давно заиспользовал
Warning: The magic method __invoke() must have public visibility and cannot be static in [...][...] on line 4
Fatal error: Uncaught Error: Call to undefined function my_function1() in [...][...]:9
Stack trace:
0 {main}
thrown in [...][...] on line 9
и вправда не работает — так бы давно заиспользовал
Warning: The magic method __invoke() must have public visibility and cannot be static in [...][...] on line 4
Fatal error: Uncaught Error: Call to undefined function my_function1() in [...][...]:9
Stack trace:
0 {main}
thrown in [...][...] on line 9
0
Для функций не нужен автолоад. Просто прописываем в composer.json:
а дальше opcache просто закэширует это дело.
"autoload": {
"files": ["src/functions.php"],
}
а дальше opcache просто закэширует это дело.
0
В классе могут содержаться всякие приватные механики, которые не светят наружу в автокомплите IDE;
0
UFO just landed and posted this here
namespace {
use LongLongNamespace\Math as Math;
echo Math\Sum(1, 2);
echo Math\Sum(1, 2);
}
вот и закончилась приватная математика Cannot redeclare LongLongNamespace\Math\PrivateSum()
use LongLongNamespace\Math as Math;
echo Math\Sum(1, 2);
echo Math\Sum(1, 2);
}
вот и закончилась приватная математика Cannot redeclare LongLongNamespace\Math\PrivateSum()
0
А если этот приватный метод потребуется в нескольких публичных?
0
а что если мне после рефакторинга нужно вынести этот 1 метод в другой класс? тогда мне будет не доступен больше тот приватный метод.
оформить в виде функции и не трахать людям мозг — это же так просто
оформить в виде функции и не трахать людям мозг — это же так просто
0
// Довольно обидно, что в read-only нельзя минусить
Речь идёт про сокрытие функций внутри функции. Вопрос был поставлен, как обеспечить приватную логику, а я уточнил, что как быть, если эта приватная логика нужна в нескольких публичных методах. Твой комментарий не уместен.
Речь идёт про сокрытие функций внутри функции. Вопрос был поставлен, как обеспечить приватную логику, а я уточнил, что как быть, если эта приватная логика нужна в нескольких публичных методах. Твой комментарий не уместен.
0
ты гониш — прочитай свой комент сначала
какое скрытие функции в другой функции? и как ты собрался скрывать функцию в функции если тебе надо ее использовать в двух методах?
А если этот приватный метод потребуется в нескольких публичных
какое скрытие функции в другой функции? и как ты собрался скрывать функцию в функции если тебе надо ее использовать в двух методах?
-1
Нет-нет. Я веду мысль к тому, что как только появляется приватная логика, то реализация на функциях начинает сливать. А если появляется необходимость вынести часть общей логики в приватную часть — то вообще не подходит.
Скажем, мы берём методы sum и sub (сложить и вычесть), но хотим складывать в какой-то важной уберфункции, которая параллельно будет что-то и логировать. Такой функцией может стать, например, приватная функция sumInternal с аргументами $a, $b, $operation (плюс, минус, умножение, etc.), а функции sum и sub будут просто вызывать её с правильными аргументами. С функциями так не выйдет, а вот с классом — без проблем.
Да, и не забывай про возможность переопределять статичные методы. Ведь этой возможности нет у функций.
Скажем, мы берём методы sum и sub (сложить и вычесть), но хотим складывать в какой-то важной уберфункции, которая параллельно будет что-то и логировать. Такой функцией может стать, например, приватная функция sumInternal с аргументами $a, $b, $operation (плюс, минус, умножение, etc.), а функции sum и sub будут просто вызывать её с правильными аргументами. С функциями так не выйдет, а вот с классом — без проблем.
Да, и не забывай про возможность переопределять статичные методы. Ведь этой возможности нет у функций.
0
и смысл прятания в чем? только в эмуляции области видимости?
и если все три функции видны и находятся в своем неймпейсе — ничего страшного нет.
- вот у нас функция sumInternal она работает с такими аргументами
- вот функции sum и sub более высокого уровня — которые используют функцию sumInternal
и если все три функции видны и находятся в своем неймпейсе — ничего страшного нет.
0
те. автокомплит IDE задает правила написания кода теперь? пишетм код не для решения задачи — а чтобы в IDE красиво и удобно было — просто офигенно.
0
Это не тот кейс, который обсуждается в статье. В статье речь идет о чистой функции — функции, которая не зависит от окружения. Зависимость от приватных полей класса — это тоже зависимость и для этого нужно использовать классы, тут я с вами согласен. Но для примера из статьи — нет.
0
просто они пишут для устаревших версий PHP где нет namespace
а все потому что годами пилили в стиле ООП фреймворк. а за это время PHP развился
а кода много переписать не реально (Yii, Symphony и подобные треш)
а все потому что годами пилили в стиле ООП фреймворк. а за это время PHP развился
а кода много переписать не реально (Yii, Symphony и подобные треш)
0
Я для себя сформировал такое правило — если функция чистая (https://ru.wikipedia.org/wiki/%D0%A7%D0%B8%D1%81%D1%82%D0%BE%D1%82%D0%B0_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8) — то её можно делать статической. Правда даже в этом случае есть проблемы — тяжело уследить когда метод перестал быть чистым и пора отрефакторить его и его использование
0
Большое количество статики за пределами utils — не слишком хороший признак как мне кажется, особенно если эта статика не является creator\фабричным методом и тем более — мутирует состояние передаваемых аргументов.
А для алгоритмов более актуальным было бы применение стратегии на мой взгляд.
А для алгоритмов более актуальным было бы применение стратегии на мой взгляд.
-1
UFO just landed and posted this here
Мне кажеться логичным использование статического метода, который возвращает имя таблицы в классе, реализующем интерфейс ActiveRecord.
0
Sign up to leave a comment.
Когда использовать статические методы